[midPoint] Manual connector questions
Alexandre Zia
alexandre.zia at ifood.com.br
Thu Sep 13 04:49:40 CEST 2018
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180912/af240832/attachment.htm>
More information about the midPoint
mailing list