[midPoint] Manual connector questions
Alexandre Zia
alexandre.zia at ifood.com.br
Thu Sep 13 06:45:24 CEST 2018
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/author
>>>> ization-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/author
>>>> ization-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/author
>>>> ization-ui-3#caseWorkItem - allows access to create a case page
>>>>
>>>> Model Authorization Actions
>>>> - http://midpoint.evolveum.com/xml/ns/public/security/author
>>>> ization-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+Resou
>>>> rce+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/provi
>>>> sioning/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/mode
>>>> l/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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20180913/6551dcb0/attachment.htm>
More information about the midPoint
mailing list