[midPoint] Manual connector questions

[Nicolas Rossi]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20181123/a66e0f27/attachment.htm>