[midPoint] Group synchronization, 3.0 SNAPSHOT

[Sam Verboven]

Hey Radovan,

Thank you for the quick and lengthy response.
I'll have a good look at all the information you've provided.

Regards,
Sam


On Wed, May 7, 2014 at 3:36 PM, Radovan Semancik <
radovan.semancik at evolveum.com> wrote:

> Hi,
>
>
> On 05/07/2014 11:55 AM, Sam Verboven wrote:
>
>>             <attribute>
>>                 <ref>icfs:groups</ref>
>>
>
> The important thing to remember here is that the "groups" attribute is not
> a real AD attribute. This is a hack in AD connector that we have inherited
> from Sun ICF. It is used only with IDM systems that are not able to handle
> groups in any other ways. However midPoint 3.0 has the ability to natively
> handle entitlements (which essentially means groups). The mechanisms is
> described here:
>
> https://wiki.evolveum.com/display/midPoint/Entitlements
>
> MidPoint should be able to work with icfs:groups pseudo-attribute as well.
> In theory. But there may be limitations and we have no intention to support
> this kind of connector hack in the future. The entitlements mechanism is
> the way forward.
>
>
>  However, I can't seem to figure out how I can sync back. A couple of
>> questions:
>>
>> 1)  If a user is added to a group in AD, how does one synchronize this
>> information back to Midpoint? I found some information using Entitlements
>> but I can't figure out if this has been fully implemented yet or how to use
>> it. Can this information be stored somewhere in the current Midpoint
>> user/role model?
>>
>
> Yes, both entitlements and generic synchronization has been fully
> implemented. However we are still in testing phase and therefore there may
> be some bugs. Despite that you are more than welcome to try it and report
> any bugs you might find.
>
> There is an example how to configure entitlements and generic
> synchronization together in our "story" test:
>
> https://wiki.evolveum.com/display/midPoint/OrgSync+Story+Test
>
> This is "outbound" synchronization and it is in fact quite complex. But
> you might be able to simplify it and turn it around for inbound sync. The
> crucial part is the schemaHandling definition in resource configuration.
> You should be able to adapt the definition from the test for your specific
> case.
>
>
>  2) Is there any method to sync the creation/deletion of the actual groups
>> themselves?
>>
>
> Yes. If you represent groups as entitlements then they become "first class
> citizens" in midPoint. And then you can use generic synchronization to pull
> them to midPoint:
>
> https://wiki.evolveum.com/display/midPoint/Generic+Synchronization
>
> The specific configuration is almost the same as for users/accounts case.
> You will just use kind=entitlement instead of kind=account. This resource
> config file has an example of synchronizing LDAP organizationalUnit to
> midPoint Orgs:
>
> https://github.com/Evolveum/midpoint/blob/master/testing/
> story/src/test/resources/orgsync/resource-opendj.xml
>
> Look especially for the second <objectSynchronization> section at the end
> of the file. You should be able to adapt this to group/Role combination.
>
>
>  3) Is adding users to groups using a role inducement even a good idea?
>>
>
> Oh yes. We are using that a lot. Just look at a way how to do that with
> entitlement association instead of this nasty "groups" AD connector
> pseudo-attribute.
>
>
>  4) An additional question regarding password synchronization. I found
>> some information about this in the FAQ :
>> https://wiki.evolveum.com/display/midPoint/Frequently+Asked+Questions#
>> FrequentlyAskedQuestions-CanmidPointsynchronizepassword
>> sfromActiveDirectoryorLDAP%3F.
>>
>> But I also found an agent on github:
>> https://github.com/Evolveum/midpoint-password-agent-ad
>>
>> Is it a good idea to use this agent, or is it simply some test code that
>> is not ready for production use?
>>
>
> It is a contributed code. We haven't tested the code ourselves but we have
> reports that it works well. However the code is using the midPoint 2.x
> version of the web service interface. Therefore it will not work with
> midPoint 3.0 in its current form. It has to be ported to the new 3.x
> version of the web service interface. However the "porting" should be
> actually very easy to do. Just fix namespace names and maybe one or two
> minor details.
>
> --
>
>                                            Radovan Semancik
>                                           Software Architect
>                                              evolveum.com
>
> _______________________________________________
> 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/20140507/fc74601b/attachment.htm>