[midPoint] Manual connector questions
Martin Lízner - AMI Praha a.s.
martin.lizner at ami.cz
Wed Nov 28 10:54:17 CET 2018
Hi, so you are doing ITSM plugin? ITSM plugin behaves in a simillar way as
ordinary connectors, so in the java part of connector you get attributes
that need to be updated. Strong mapping only really says how the update
should be calculated on mp side, but if the value is not to be changed,
connector will not get the information afaik.
Maybe there is a way to force midpoint to send attribute anyway. I havent
investigate it alot, but this ugly workaround may be possible:
- Create any-strength mapping on this "additional" attribute
- Make sure plugin always return empty value when reading the attribute
- Midpoint will try to update the attribute with every user recompute
- Filter out attribute on connector level - e.g. if only this "additional"
attribute is changed and no other, dont create actual ticket
The (big) downside is that mp will try to update such manual account every
time it has a chance. Therefore I cant really recommend it, but maybe
somebody knows better way, Im no ICF expert :-)
Also you can try to remotely connect to midPoint from the actual connector
java and retrieve information from UserType. This may be even uglier hack
since it criples architecture with critical dependencies.
M.
*Martin Lízner*
chief solution architect
gsm: [+420] 737 745 571
e‑mail: martin.lizner at ami.cz
*AMI Praha a.s.*
Pláničkova 11, 162 00 Praha 6
tel.: [+420] 274 783 239 | web: www.ami.cz
[image: AMI Praha a.s.]
Textem tohoto e‑mailu podepisující neslibuje uzavřít ani neuzavírá
za společnost AMI Praha a.s.
jakoukoliv smlouvu. Každá smlouva, pokud bude uzavřena, musí mít výhradně
písemnou formu.
Tento e‑mail je určen výhradně pro potřeby jeho adresáta/ů a může obsahovat
důvěrné nebo osobní
informace. Nejste‑li zamýšleným příjemcem, je zakázáno jakékoliv
zveřejňování, zprostředkování
nebo jiné použití těchto informací. Pokud jste obdrželi e‑mail neoprávněně,
informujte o tom prosím
odesílatele a vymažte neprodleně všechny kopie tohoto e‑mailu včetně
všech jeho příloh. Nakládáním
s neoprávněně získanými informacemi se vystavujete riziku právního postihu.
pá 23. 11. 2018 v 19:39 odesílatel Nicolas Rossi <nrossi at identicum.com>
napsal:
> Hi guys, we are also developing a Manual Connector for Jira. It is almost
> done and It works fine but there is an issue: we defined some mappings
> with strong strength but it didn't work. There is no reference to this
> attributes on the changes collection unless they were changed.
>
> Have you tried it ?
>
>
> Ing Nicolás Rossi
> Identicum S.A.
> Jorge Newbery 3226
> Oficina: +54 (11) 4552-3050
> Móvil: +54 (911) 6041-3920
> www.identicum.com
>
>
> On Thu, Sep 13, 2018 at 1:49 AM Alexandre Zia <alexandre.zia at ifood.com.br>
> wrote:
>
>> Other small issue,
>>
>> When I ran in My PC using embedded database it all went well.
>> On my Server using PostgreSQL and midpoint crashed because
>>
>> Caused by: org.hibernate.tool.schema.spi.SchemaManagementException:
>> Schema-validation: missing column [comment] in table [m_case_wi]
>>
>> Had to mannually create 2 fields :
>>
>> ALTER TABLE public.m_case_wi ADD comment varchar(255) NULL;
>> ALTER TABLE public.m_case ADD description varchar(255) NULL;
>>
>> And all went well,
>>
>>
>>
>> On Wed, Sep 12, 2018 at 11:49 PM, Alexandre Zia <
>> alexandre.zia at ifood.com.br> wrote:
>>
>>> Hey Brandon,
>>> Thanks again
>>>
>>> Managed to apply your Pull Request over "3.8-support" branch and it
>>> worked as expected !
>>>
>>> however I think I may have found a small issue, not sure if is a bug to
>>> be honest, but worth mention:
>>>
>>> Worked like a charm if using Grace period, like this :
>>>
>>> <consistency>
>>> <pendingOperationGracePeriod>PT15M</pendingOperationGracePeriod>
>>> </consistency>
>>>
>>> But if not using grace period it did not remove the shadow on delete,
>>> neither marked it as <dead>true</dead>
>>>
>>> Not a big deal though, I tested with grace period of 1 second and it
>>> worked.
>>>
>>> Thanks again for this contribution
>>> Regards Alexandre
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Sep 12, 2018 at 8:24 PM, Brandon Powers <
>>> brandon at exclamationlabs.com> wrote:
>>>
>>>> Alexandre,
>>>>
>>>>
>>>> * - Once operators close the case, "shadow refresh task" process the
>>>> shadows, but shadows still contain the related pending operations not
>>>> closed / finished*
>>>> * - If it is a delete account operation, Shadow account is not
>>>> deleted and we have to delete the shadows manually*
>>>>
>>>> You are correct assuming that there is an issue with the pending
>>>> operations being applied to the shadow attributes. This is an issue we
>>>> recently identified ourselves. We have applied a fix and submitted a Pull
>>>> Request for inclusion in a future midPoint release.
>>>>
>>>> In the mean time, we currently use a custom task script to delete
>>>> shadows containing a pending delete operation.
>>>>
>>>> The pull request is here for reference:
>>>> https://github.com/Evolveum/midpoint/pull/85
>>>> With these changes, the shadow refresh task correctly updates shadow
>>>> (cache) attributes as well as removes deleted shadows. Pending operations
>>>> that are completed are also removed from the shadow.
>>>>
>>>> Note, we are also working on a fix to the shadow refresh task to update
>>>> the shadow *name* when a namingAttribute is modified.
>>>>
>>>> Hope this helps.
>>>> Brandon
>>>>
>>>> On Wed, Sep 12, 2018 at 5:27 PM Alexandre Zia <
>>>> alexandre.zia at ifood.com.br> wrote:
>>>>
>>>>> Hi Brandon,
>>>>>
>>>>> Thanks for the thorough explanation about manual connector
>>>>> And double thanks about your company contribution to Midpoint
>>>>> regarding the cases UI and everything related.
>>>>>
>>>>> It took me a while to put all of this to work according to your
>>>>> instructions because we were stuck on MP 3.7.2 , I had to make Google
>>>>> connector work with MP 3.8 and upgrade our MP Prod server cluster.
>>>>>
>>>>> Now we did several tests and configuration on manual connectors, and
>>>>> we have almost everything working as expected, however still have small
>>>>> issues that I would like to check if we are doing something wrong or if
>>>>> this is how MP works.
>>>>>
>>>>> - We have created and configured manual connector resource
>>>>> - We have created a "shadow refresh task"
>>>>>
>>>>> - Users are able to request Roles
>>>>> - MP put the requests under Approval Workflow
>>>>> - Once requests are approved a case is started, email notifications
>>>>> are sent to operators asking them to execute the changes and close the case
>>>>> - Operators close the case
>>>>>
>>>>> - At this point, I would like to get advice:
>>>>> - Once operators close the case, "shadow refresh task" process the
>>>>> shadows, but shadows still contain the related pending operations not
>>>>> closed / finished
>>>>> - If it is a delete account operation, Shadow account is not
>>>>> deleted and we have to delete the shadows manually
>>>>>
>>>>> Is this behavior ok?
>>>>> MP will not delete the shadows even after operator close the delete
>>>>> account case?
>>>>> Is the same for other operations? pending operations will remain in
>>>>> the shadow?
>>>>>
>>>>> Looking at the shadows, after Operatos closes the case, the pending
>>>>> operation shows "unknown" resultStatus:
>>>>> <executionStatus>executing</executionStatus>
>>>>> <resultStatus>unknown</resultStatus>
>>>>>
>>>>> I'm trying to test now semi-manual Resource using Manual-Connector as
>>>>> base connector and Scripted-Rest-Connector as additional connector
>>>>> Because we have several systems were we have to manually create,
>>>>> delete and modify accounts, but we have REST API to list users and get
>>>>> users details
>>>>> This way MP will be able to verify if the remote system status is the
>>>>> way it should be according to MP state,
>>>>> Do you think this semi-manual resource will be able to update the
>>>>> shadows, finishing pending operations, deleting shadows, etc?
>>>>>
>>>>> Thais again,
>>>>> Alexandre
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Sep 5, 2018 at 10:39 AM, Brandon Powers <
>>>>> brandon at exclamationlabs.com> wrote:
>>>>>
>>>>>> Hello,
>>>>>> We have provided the following information in a similar question from
>>>>>> another contact. Hope this helps (I know its a long response, but I've
>>>>>> tried to explain the manual resource / case process well):
>>>>>>
>>>>>> The MidPoint Cases UI is a combination of pages allowing
>>>>>> administrators to view, close, and audit cases both created automatically
>>>>>> using manual/semi-manual resource connectors, and those created manually by
>>>>>> the user.
>>>>>>
>>>>>> A quick overview of cases and case work items:
>>>>>> A case is a task that needs to be completed associated with a
>>>>>> particular resource, and most often, a change to a resource account
>>>>>> (shadow). A case is assigned to users through "case work items". A case
>>>>>> can have any number of case work items. Each case work item is assigned to
>>>>>> a single user. Closing any case work item closes the entire case.
>>>>>>
>>>>>> To view the Cases UI, simply add the appropriate authorizations for
>>>>>> the user roles needing access. Here are some common authorizations:
>>>>>>
>>>>>> UI Authorization Actions
>>>>>> -
>>>>>> http://midpoint.evolveum.com/xml/ns/public/security/authorization-ui-3#caseWorkItemsAll -
>>>>>> enables the "All case work items" page showing all case work items assigned
>>>>>> to any user.
>>>>>> -
>>>>>> http://midpoint.evolveum.com/xml/ns/public/security/authorization-ui-3#caseWorkItemsAllocatedToMe -
>>>>>> enables the "My case work items" page showing all case work items assigned
>>>>>> to the logged in user.
>>>>>> -
>>>>>> http://midpoint.evolveum.com/xml/ns/public/security/authorization-ui-3#caseWorkItem -
>>>>>> allows access to create a case page
>>>>>>
>>>>>> Model Authorization Actions
>>>>>> -
>>>>>> http://midpoint.evolveum.com/xml/ns/public/security/authorization-model-3#readAllWorkItems -
>>>>>> used in conjunction with object type `CaseWorkItemType`, allows reading all
>>>>>> case work items
>>>>>> - Standard model actions in conjunction with object type `CaseType`
>>>>>> to allow read/modify/etc access on Cases
>>>>>>
>>>>>> Once the appropriate authorizations are present, the Cases UI will be
>>>>>> accessible from the menu
>>>>>> Work Items -> All Cases - All Case objects
>>>>>> Work Items -> My Cases - All case objects assigned to logged in user
>>>>>> Work Items -> All Case Work Items - all case work items, filterable
>>>>>> by resource, actor (assignee), and case state (open/closed)
>>>>>> Work Items -> My Case Work Items - all case work items assigned to
>>>>>> the logged in user
>>>>>>
>>>>>> Clicking on the case work item "description" in the table will
>>>>>> display a page showing detailed information about the case and case work
>>>>>> item, such as assignee, timestamps, change deltas, etc. This page also
>>>>>> offers the ability to "close" the case with option to add a comment or
>>>>>> upload a file for evidence (useful for purely manual resources where
>>>>>> midPoint has no way of accurately knowing the result of a change on an
>>>>>> external system, provides evidence for auditing purposes).
>>>>>>
>>>>>> Cases are automatically generated by midPoint for manual and
>>>>>> semi-manual resources when their respective resource accounts (shadows)
>>>>>> change (account details such as first/last name, or entitlements such as
>>>>>> permission/roles).
>>>>>>
>>>>>> For this to happen, a resource must be configured with the connector
>>>>>> type `ManualConnector`. Additionally, another connector may be specified
>>>>>> as an `additionalConnnector` for semi-manual resources (see
>>>>>> https://wiki.evolveum.com/display/midPoint/Manual+Resource+Configuration#ManualResourceConfiguration-Semi-ManualResources
>>>>>> )
>>>>>> To specify users that should be assigned to the automatically
>>>>>> generated cases, you must add business operators to the resource. See the
>>>>>> example here:
>>>>>> https://github.com/Evolveum/midpoint/blob/master/provisioning/provisioning-impl/src/test/resources/manual/resource-manual.xml
>>>>>> (Note that `operatorRef`s can include a specific user OID, or a
>>>>>> filter can be used to select a user based on attributes, such as username.
>>>>>>
>>>>>> Additionally, if you would like email notifications, the
>>>>>> `simpleCaseManagementNotifier` can be configured in the system
>>>>>> configuration. (I don't believe Evolveum has any documentation on this yet
>>>>>> either, but it operates similar to the other notifiers. Here is a link to
>>>>>> the class:
>>>>>> https://github.com/Evolveum/midpoint/blob/master/model/notifications-impl/src/main/java/com/evolveum/midpoint/notifications/impl/notifiers/SimpleCaseManagementNotifier.java
>>>>>> )
>>>>>>
>>>>>> As you mentioned, there is also the option to use ITSM plugin instead
>>>>>> of the internal midPoint case management functionality.
>>>>>>
>>>>>> - Brandon
>>>>>>
>>>>>> On Wed, Sep 5, 2018 at 3:24 AM Radovan Semancik <
>>>>>> radovan.semancik at evolveum.com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Manual connectors are quite an interesting functionality of
>>>>>>> midPoint. However, it was created in small parts. It was never a completely
>>>>>>> funded work. As mostly unfunded work we have focused on the code. The code
>>>>>>> is solid, and in fact it recently went over a significant consolidation and
>>>>>>> cleanup as part of Galileo development. However, the documentation leaves
>>>>>>> much to be desired. We have made significant investment to manual connector
>>>>>>> functionality during last few years. And unfortunately, we do not have any
>>>>>>> more resources to invest even more funds in the documentation.
>>>>>>>
>>>>>>> Therefore I can only recommend the options that I'm recommending all
>>>>>>> the time (with a little twist):
>>>>>>>
>>>>>>> 1) Get midPoint subscription. Ideally platform subscription. Income
>>>>>>> from the subscription can be used to improve documentation.
>>>>>>>
>>>>>>> 2) Sponsor the work on midPoint book:
>>>>>>>
>>>>>>> https://evolveum.com/midpoint/midpoint-guide-about-practical-identity-management/
>>>>>>> The book was praised by many people. However, Evolveum has been the
>>>>>>> only sponsor of this effort so far. It was quite an effort already. But
>>>>>>> there is still too many things to write down. And the book is not going to
>>>>>>> write itself. I can do it. In fact, I would absolutely love to do it. But
>>>>>>> further work on the book needs funding.
>>>>>>>
>>>>>>> 3) Source code is available. You can read through the code and
>>>>>>> contribute the documentation.
>>>>>>>
>>>>>>> I know that this answer does not help much. But asking questions
>>>>>>> without contributing anything back is not going to help the project either.
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Radovan Semancik
>>>>>>> Software Architectevolveum.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 09/04/2018 04:16 AM, Alexandre Zia wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I'm Having a hard time trying to understand how manual connector
>>>>>>> actually works.
>>>>>>> I've tried several approaches, but always end up with some
>>>>>>> "collateral effects"
>>>>>>> I've read all I could find about manual resources, MP Confluence,
>>>>>>> mailing list,
>>>>>>> provisioned all the examples, tried several different configs,
>>>>>>> but the fact
>>>>>>> is that there is no comprehensive explanation on how manual
>>>>>>> resources works
>>>>>>> So I'm asking for help here at least to check if I'm doing
>>>>>>> something terrible wrong
>>>>>>>
>>>>>>> 1. Pure manual connector:
>>>>>>>
>>>>>>> - Created Role to induce account creation works fine,
>>>>>>>
>>>>>>> - Upon role assignment the resulting operation it creates a
>>>>>>> shadow for the
>>>>>>> account in the connector, however the assignment operation never
>>>>>>> completes,
>>>>>>> stays in IN_PROGRESS forever and the shadows keeps
>>>>>>> pendingOperations and
>>>>>>> there is no way to get rid of them.
>>>>>>>
>>>>>>> - Upon role unassignment the role is unassigned but the
>>>>>>> projection in the
>>>>>>> resource (shadow) is not removed, stays there forever until we
>>>>>>> manually
>>>>>>> delete the shadow and run a reconciliation
>>>>>>>
>>>>>>> 2. Semi manual with CSV connector as additionalConnector:
>>>>>>>
>>>>>>> - Same as above, except:
>>>>>>>
>>>>>>> - I can see the accounts appearing in resource
>>>>>>> (Accounts tab in resource, searching in the resource side)
>>>>>>> when the accounts appears in the CSV, but seems to do
>>>>>>> nothing
>>>>>>> regarding the shadow.
>>>>>>>
>>>>>>> - when unassigning the role, same thing, when the account
>>>>>>> vanishes from CSV
>>>>>>> nothing happens to the shadow and the projection remains
>>>>>>>
>>>>>>> I have also created a Shadow Refresh Task, and it even reports that
>>>>>>> is processing the shadows, but nothing changes actually.
>>>>>>>
>>>>>>> Other thing we are trying to do here is how to notify operator
>>>>>>> when he needs
>>>>>>> to manually create or delete the accounts?
>>>>>>> We have created an extra approval named something like: "Wait for
>>>>>>> the
>>>>>>> operator to create the account" but again there is room for
>>>>>>> improvement here:
>>>>>>> - We have approvers assigned to the role and an approval stage
>>>>>>> - So we have added operators as "owners" and filtering the "wait
>>>>>>> for the
>>>>>>> operator" approval by the "owner" but this is not working
>>>>>>> properly.
>>>>>>>
>>>>>>> Can someone share a bit about the subject?
>>>>>>> What is the best approach to work with manual connectors?
>>>>>>>
>>>>>>> If we setup an ITSM plugin (we use Jira here) will it work as
>>>>>>> expected?
>>>>>>> By expected I mean will the assignments and unassignments work
>>>>>>> properly?
>>>>>>> The projections will be deleted upon unassignments?
>>>>>>> ITSM plugin is the right way to notify operators?
>>>>>>>
>>>>>>>
>>>>>>> Thanks for reading the entire email, I know it's huge ;)
>>>>>>>
>>>>>>> Regards,
>>>>>>> Alexandre
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> midPoint mailing list
>>>>>>> midPoint at lists.evolveum.com
>>>>>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>>>>>>
>>>>>> --
>>>>>> Brandon Powers
>>>>>> Exclamation Labs
>>>>>> 300 Washington Street
>>>>>> Cumberland, MD 21502
>>>>>> 888.545.5008 or 301.722.5008 ext 144
>>>>>> fax 301.722.2183
>>>>>> brandon at exclamationlabs.com
>>>>>> www.exclamationlabs.com
>>>>>>
>>>>>> _______________________________________________
>>>>>> midPoint mailing list
>>>>>> midPoint at lists.evolveum.com
>>>>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Alexandre Roberto Zia
>>>>>
>>>>> *Security*
>>>>>
>>>>> *TEL:* +55 (11) 3634-3360
>>>>>
>>>>> www.ifood.com.br
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> <https://itunes.apple.com/br/app/ifood-delivery-e-entrega-comida/id483017239?mt=8>
>>>>> <https://play.google.com/store/apps/details?id=br.com.brainweb.ifood>
>>>>> <https://www.facebook.com/iFood?fref=ts> <https://twitter.com/iFood>
>>>>> _______________________________________________
>>>>> midPoint mailing list
>>>>> midPoint at lists.evolveum.com
>>>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>>>>
>>>> --
>>>> Brandon Powers
>>>> Exclamation Labs
>>>> 300 Washington Street
>>>> Cumberland, MD 21502
>>>> 888.545.5008 or 301.722.5008 ext 144
>>>> fax 301.722.2183
>>>> brandon at exclamationlabs.com
>>>> www.exclamationlabs.com
>>>>
>>>> _______________________________________________
>>>> midPoint mailing list
>>>> midPoint at lists.evolveum.com
>>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Alexandre Roberto Zia
>>>
>>> *Security*
>>>
>>> *TEL:* +55 (11) 3634-3360
>>>
>>> www.ifood.com.br
>>>
>>>
>>>
>>>
>>> <https://itunes.apple.com/br/app/ifood-delivery-e-entrega-comida/id483017239?mt=8>
>>> <https://play.google.com/store/apps/details?id=br.com.brainweb.ifood>
>>> <https://www.facebook.com/iFood?fref=ts> <https://twitter.com/iFood>
>>>
>>
>>
>>
>> --
>>
>> Alexandre Roberto Zia
>>
>> *Security*
>>
>> *TEL:* +55 (11) 3634-3360
>>
>> www.ifood.com.br
>>
>>
>>
>>
>> <https://itunes.apple.com/br/app/ifood-delivery-e-entrega-comida/id483017239?mt=8>
>> <https://play.google.com/store/apps/details?id=br.com.brainweb.ifood>
>> <https://www.facebook.com/iFood?fref=ts> <https://twitter.com/iFood>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20181128/ada4ee04/attachment.htm>
More information about the midPoint
mailing list