[midPoint] Multiple IDs (correlation) on resource
Jason Everling
jeverling at bshp.edu
Sat Feb 11 20:15:24 CET 2017
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20170211/369d6863/attachment.htm>
More information about the midPoint
mailing list