[midPoint] Multiple IDs (correlation) on resource

Ivan Noris Ivan.Noris at evolveum.com
Fri Feb 10 20:48:15 CET 2017 

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 

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

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

More information about the midPoint mailing list