[midPoint] Multiple IDs (correlation) on resource

Ivan Noris Ivan.Noris at evolveum.com
Sun Feb 12 19:05:28 CET 2017 

Hi Jason, 

this feature was implemented exactly for such reasons - I have a customer with more than 20 intents in AD/Exchange; having more than 20 resources would be quite un-managable. 

Ivan 

----- Original Message -----

> From: "Jason Everling" <jeverling at bshp.edu>
> To: "midPoint General Discussion" <midpoint at lists.evolveum.com>
> Sent: Saturday, February 11, 2017 8:15:24 PM
> Subject: Re: [midPoint] Multiple IDs (correlation) on resource

> Ok thanks, that is helpful so i know it can be done now. I didnt want to have
> to create 2 objects for the same resource,

> JASON

> On Fri, Feb 10, 2017 at 1:48 PM, Ivan Noris < Ivan.Noris at evolveum.com >
> wrote:

> > Hi Jason,
> 
> > well, multiple intents could be used for what you need, if... :
> 

> > 1) you can define what the policies for login (icfs:name) would be - this
> > is
> > what you already have/know
> 
> > 2) you can distinguish between the intents by algorithm when synchronizing
> 

> > The schema handling is quite simple, but for each objectType in
> > schemaHandling you need a corresponding objectSynchronization in
> > synchronization part. Each objectSynchronization should have a condition,
> > so
> > that midPoint will use exactly one objectSynchronization. As connector only
> > returns "account", decision about intent is done in midPoint
> > synchronization.
> 

> > An example from our training: I have two intents (default and admin); they
> > differ only in suffix in DN (otherwise they are completely equal). In your
> > case the correlation expressions would differ of course. But the thing is:
> > midPoint will apply all the conditions on any discovered account, and for
> > any which resolves to true, will use the kind/intent from that
> > objectSynchronization and set it in the shadow.
> 

> > So if you can have the condition which will in fact just decide what
> > kind/intent the shadow is, you can have then different correlation rules.
> 

> > Is that possible in your case? Can you differentiate them?
> 
> > (I have just finished a training today so this came to my mind...)
> 

> > <synchronization>
> 
> > <objectSynchronization>
> 
> > <!--
> 
> > The synchronization for this resource is enabled.
> 
> > It means that the synchronization will react to changes detected by
> 
> > the system (live sync task, discovery or reconciliation) -->
> 
> > <name>Default account</name>
> 
> > <description>Normal accounts are NOT in ou=_Administrators
> > container</description>
> 
> > <kind>account</kind>
> 
> > <intent>default</intent>
> 
> > <enabled>true</enabled>
> 
> > <condition>
> 
> > <script>
> 
> > <code>
> 
> > import static com.evolveum.midpoint.schema.constants.SchemaConstants.*
> 
> > tmpSuffix = '(?i).*,ou=_Administrators_,ou=ExAmPLE,dc=example,dc=com$'
> 
> > re = ~tmpSuffix
> 
> > !(basic.getAttributeValue(shadow, ICFS_NAME) ==~ re)
> 
> > </code>
> 
> > </script>
> 
> > </condition>
> 
> > <correlation>
> 
> > <q:description>
> 
> > Correlation expression is a search query.
> 
> > Following search queury will look for users that have "employeeNumber"
> 
> > equal to the "employeeNumber" attribute of the account.
> 
> > The condition will ensure that "employeeNumber" is not
> 
> > empty, otherwise it would match any midPoint user
> 
> > with empty "employeeNumber" attribute, such as "administrator".
> 
> > The correlation rule always looks for users, so it will not match
> 
> > any other object type.
> 
> > </q:description>
> 
> > <q:equal>
> 
> > <q:path>c:employeeNumber</q:path>
> 
> > <expression>
> 
> > <path>$account/attributes/ri:employeeNumber</path>
> 
> > </expression>
> 
> > </q:equal>
> 
> > <condition>
> 
> > <script>
> 
> > <code>basic.getAttributeValue(shadow, 'employeeNumber') != null</code>
> 
> > </script>
> 
> > </condition>
> 
> > </correlation>
> 

> > <!-- Confirmation rule may be here, but as the search above will
> 
> > always return at most one match, the confirmation rule is not needed. -->
> 

> > <!-- Following section describes reactions to a situations.
> 
> > The setting here assumes that this resource is authoritative,
> 
> > therefore all accounts created on the resource should be
> 
> > reflected as new users in IDM.
> 
> > See http://wiki.evolveum.com/display/midPoint/Synchronization+Situations
> 
> > -->
> 
> > <reaction>
> 
> > <situation>linked</situation>
> 
> > <synchronize>true</synchronize>
> 
> > </reaction>
> 
> > <reaction>
> 
> > <situation>deleted</situation>
> 
> > <synchronize>true</synchronize>
> 
> > <action>
> 
> > <handlerUri>
> > http://midpoint.evolveum.com/xml/ns/public/model/action-3#unlink
> > </handlerUri>
> 
> > </action>
> 
> > </reaction>
> 
> > <reaction>
> 
> > <situation>unlinked</situation>
> 
> > <synchronize>true</synchronize>
> 
> > <action>
> 
> > <handlerUri> http://midpoint.evolveum.com/xml/ns/public/model/action-3#link
> > </handlerUri>
> 
> > </action>
> 
> > </reaction>
> 
> > <reaction>
> 
> > <situation>unmatched</situation>
> 
> > </reaction>
> 
> > </objectSynchronization>
> 

> > <objectSynchronization>
> 
> > <name>Admin account</name>
> 
> > <description>Admin accounts are in ou=_Administrators
> > container</description>
> 
> > <kind>account</kind>
> 
> > <intent>admin</intent>
> 
> > <enabled>true</enabled>
> 
> > <condition>
> 
> > <script>
> 
> > <code>
> 
> > import static com.evolveum.midpoint.schema.constants.SchemaConstants.*
> 
> > tmpSuffix = '(?i).*,ou=_Administrators_,ou=ExAmPLE,dc=example,dc=com$'
> 
> > re = ~tmpSuffix
> 
> > basic.getAttributeValue(shadow, ICFS_NAME) ==~ re
> 
> > </code>
> 
> > </script>
> 
> > </condition>
> 
> > <correlation>
> 
> > <q:description>
> 
> > Correlation expression is a search query.
> 
> > Following search queury will look for users that have "employeeNumber"
> 
> > equal to the "employeeNumber" attribute of the account.
> 
> > The condition will ensure that "employeeNumber" is not
> 
> > empty, otherwise it would match any midPoint user
> 
> > with empty "employeeNumber" attribute, such as "administrator".
> 
> > The correlation rule always looks for users, so it will not match
> 
> > any other object type.
> 
> > </q:description>
> 
> > <q:equal>
> 
> > <q:path>c:employeeNumber</q:path>
> 
> > <expression>
> 
> > <path>$account/attributes/ri:employeeNumber</path>
> 
> > </expression>
> 
> > </q:equal>
> 
> > <condition>
> 
> > <script>
> 
> > <code>basic.getAttributeValue(shadow, 'employeeNumber') != null</code>
> 
> > </script>
> 
> > </condition>
> 
> > </correlation>
> 

> > <reaction>
> 
> > <situation>linked</situation>
> 
> > <synchronize>true</synchronize>
> 
> > </reaction>
> 
> > <reaction>
> 
> > <situation>deleted</situation>
> 
> > <synchronize>true</synchronize>
> 
> > <action>
> 
> > <handlerUri>
> > http://midpoint.evolveum.com/xml/ns/public/model/action-3#unlink
> > </handlerUri>
> 
> > </action>
> 
> > </reaction>
> 
> > <reaction>
> 
> > <situation>unlinked</situation>
> 
> > <synchronize>true</synchronize>
> 
> > <action>
> 
> > <handlerUri> http://midpoint.evolveum.com/xml/ns/public/model/action-3#link
> > </handlerUri>
> 
> > </action>
> 
> > </reaction>
> 
> > <reaction>
> 
> > <situation>unmatched</situation>
> 
> > </reaction>
> 
> > </objectSynchronization>
> 
> > </synchronization>
> 
> > </c:resource>
> 

> > </c:objects>
> 

> > Best regards,
> 
> > Ivan
> 

> > > From: "Jason Everling" < jeverling at bshp.edu >
> > 
> 
> > > To: "midPoint General Discussion" < midpoint at lists.evolveum.com >
> > 
> 
> > > Sent: Friday, February 10, 2017 3:40:02 PM
> > 
> 
> > > Subject: Re: [midPoint] Multiple IDs (correlation) on resource
> > 
> 

> > > Well not really, though that is much needed feature. What I was referring
> > > too, the different person types use different icfs:name as the
> > > identifier,
> > > so..
> > 
> 

> > > On the same resource, faculty/staff/contractors/etc. . would have to
> > > match
> > > using 'name' , their campus id does not exist on the resource, only
> > > username.
> > 
> 
> > > <attribute>
> > 
> 
> > > <c:ref>icfs:name</c:ref>
> > 
> 
> > > <displayName>Name</displayName>
> > 
> 
> > > <limitations>
> > 
> 
> > > <minOccurs>0</minOccurs>
> > 
> 
> > > <access>
> > 
> 
> > > <read>true</read>
> > 
> 
> > > </access>
> > 
> 
> > > </limitations>
> > 
> 
> > > <inbound>
> > 
> 
> > > <target>
> > 
> 
> > > <c:path>$user/name</c:path>
> > 
> 
> > > </target>
> > 
> 
> > > </inbound>
> > 
> 
> > > </attribute>
> > 
> 

> > > and students/alumni/guests would need to match using their campus id and
> > > their username is not on resource, only campus id
> > 
> 

> > > <attribute>
> > 
> 
> > > <c:ref>icfs:name</c:ref>
> > 
> 
> > > <displayName>Name</displayName>
> > 
> 
> > > <limitations>
> > 
> 
> > > <minOccurs>0</minOccurs>
> > 
> 
> > > <access>
> > 
> 
> > > <read>true</read>
> > 
> 
> > > </access>
> > 
> 
> > > </limitations>
> > 
> 
> > > <inbound>
> > 
> 
> > > <target>
> > 
> 
> > > <c:path>$c:user/c:extension/bshp:campusID</c:path>
> > 
> 
> > > </target>
> > 
> 
> > > </inbound>
> > 
> 
> > > </attribute>
> > 
> 

> > > JASON
> > 
> 

> > > On Fri, Feb 10, 2017 at 4:12 AM, Davy Priem < davy.priem at vives.be >
> > > wrote:
> > 
> 

> > > > Hi Jason,
> > > 
> > 
> 

> > > > On the roadmap I see they will introduce ‘Personas: (identity links):
> > > > Ability
> > > > to link user objects representing physical person and his personas,
> > > > e.g.
> > > > employee persona, administration persona, etc.’. Isn’t this what you’re
> > > > looking for?
> > > 
> > 
> 

> > > > Best regards,
> > > 
> > 
> 

> > > > Davy Priem
> > > 
> > 
> 

> > > > Van: midPoint [mailto: midpoint-bounces at lists.evolveum.com ] Namens
> > > > Jason
> > > > Everling
> > > 
> > 
> 
> > > > Verzonden: dinsdag 7 februari 2017 1:49
> > > 
> > 
> 
> > > > Aan: midPoint General Discussion < midpoint at lists.evolveum.com >
> > > 
> > 
> 
> > > > Onderwerp: [midPoint] Multiple IDs (correlation) on resource
> > > 
> > 
> 

> > > > I am working on adding a resource in which each type of person can have
> > > > a
> > > > different ID, (uuid) , such as faculty/staff/contractors/etc.. would
> > > > match
> > > > using their username (name) and students/alumni/guests would match
> > > > using
> > > > their campus id.
> > > 
> > 
> 

> > > > I couldn't find too much on this or samples, does anybody have anything
> > > > similar?
> > > 
> > 
> 

> > > > This kind of resource is new to me but reading up on the wiki I am
> > > > leaning
> > > > towards multiple (intents)??? Would that be down the right road? For
> > > > example
> > > 
> > 
> 

> > > > <objectType>
> > > 
> > 
> 

> > > > <displayName>Student Account</displayName>
> > > 
> > 
> 

> > > > <intent>studentAccount</intent>
> > > 
> > 
> 

> > > > <default>true</default>
> > > 
> > 
> 

> > > > ....
> > > 
> > 
> 

> > > > ...
> > > 
> > 
> 

> > > > </objectType>
> > > 
> > 
> 

> > > > <objectType>
> > > 
> > 
> 

> > > > <displayName>Staff Account</displayName>
> > > 
> > 
> 

> > > > <intent>staffAccount</intent>
> > > 
> > 
> 

> > > > <default>true</default>
> > > 
> > 
> 

> > > > ....
> > > 
> > 
> 

> > > > ...
> > > 
> > 
> 

> > > > </objectType>
> > > 
> > 
> 

> > > > <synchronization>
> > > 
> > 
> 

> > > > <objectSynchronization>
> > > 
> > 
> 

> > > > <enabled>true</enabled>
> > > 
> > 
> 

> > > > <intent>studentAccount</intent>
> > > 
> > 
> 

> > > > <correlation>
> > > 
> > 
> 

> > > > <q:equal>
> > > 
> > 
> 

> > > > <q:path>c:extension/bshp:campusID</q:path>
> > > 
> > 
> 

> > > > ........
> > > 
> > 
> 

> > > > .......
> > > 
> > 
> 

> > > > </objectSynchronization>
> > > 
> > 
> 

> > > > <objectSynchronization>
> > > 
> > 
> 

> > > > <enabled>true</enabled>
> > > 
> > 
> 

> > > > <intent>staffAccount</intent>
> > > 
> > 
> 

> > > > <correlation>
> > > 
> > 
> 

> > > > <q:equal>
> > > 
> > 
> 

> > > > <q:path>c:name</q:path>
> > > 
> > 
> 

> > > > ........
> > > 
> > 
> 

> > > > .......
> > > 
> > 
> 

> > > > </objectSynchronization>
> > > 
> > 
> 

> > > > </synchronization>
> > > 
> > 
> 

> > > > Any help is always appreciated!
> > > 
> > 
> 

> > > > JASON
> > > 
> > 
> 

> > > > _______________________________________________
> > > 
> > 
> 
> > > > 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
> > 
> 

> > --
> 
> > Ivan Noris
> 
> > Senior Identity Engineer
> 
> > evolveum.com
> 

> > _______________________________________________
> 
> > 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

-- 
Ivan Noris 
Senior Identity Engineer 
evolveum.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20170212/f24d427b/attachment.htm>

More information about the midPoint mailing list