[midPoint] Sync Entitlements to Role Object with DatabaseTableConnector
Ivan Noris
ivan.noris at evolveum.com
Tue May 3 09:34:40 CEST 2016
Hi,
On 05/03/2016 09:13 AM, Harits Elfahmi wrote:
> Hi Ivan,
>
> From what I read groups and users are saved at the same resource in
> LDAP, associating them would be as you said. But I'm using
> DatabaseTableConnector, and my roles and users data are in separate
> table in my database. To connect them to midpoint, I create two
> resource, one that connect to the users table, and another that
> connect to the roles table. Is it possible to associate them in
> midpoint, or is this the limitation of the DatabaseTableConnector?
>
DBTable connector is currently limited to support only one table (that's
also why its configuration is so simple). The other limitations that I
know of:
- it supports only accounts (AccountObjectClass) - if you use "accounts"
as projection of roles, it works
- it supports only simple primary keys (not complex ones)
- it does not support entitlements/associations
I think you have several possibilities:
1) keep using DB Table connector, and on the DB side construct a view
which will contain the user attributes as well as group membership. As
DB Table does not really support anything else than accounts (everything
is "accounts") you may skip using the association and just use some
multivalue attribute of the account (in the DB View) to provision to the
groups. I don't remember if I tried this recently and I hope that the
connector support the multivalue attributes. If this works, it will be
the simplest (but not prettiest) solution.
You may still need two resources, one for managing accounts (including
group membership using view attribute) and one for managing roles as you
originally wanted for synchronizing with midPoint roles.
2) try ScriptedSQL connector. You can twist and bend it to support any
database, any table combination. So it can be configured to support
entitlements and associations as well. This will require you to script
the behaviour Create/Update/Read/Delete/Search/Schema etc. operations
(Groovy or Javascript). One resource will be enough.
Some samples:
https://github.com/Evolveum/midpoint/tree/master/samples/resources/scriptedsql
3) create custom DB connector. That's almost the same as ScriptedSQL,
but compiled (java) and not interpreted, so it should be faster.
https://wiki.evolveum.com/display/midPoint/Connector+Development+HOWTO
[last but not least 4) the DB Table connector can be enhanced for
multiple-table / entitlement / association support, by contributing or
sponsoring such feature as documented in
https://wiki.evolveum.com/display/midPoint/I+Need+New+Feature]
Regards,
Ivan
> Thanks
>
> 2016-05-03 13:50 GMT+07:00 Ivan Noris <ivan.noris at evolveum.com
> <mailto:ivan.noris at evolveum.com>>:
>
> Hi,
>
> not sure if I understand how entitlement and account could be on
> different resources. But the answer is - associations works only
> if the entitlements and accounts are on the SAME resource.
>
> If you think of entitlements as "groups" (most common entitlement
> on resources), association configuration is just an information
> for midPoint about "how to get all account's groups" or "how to
> provision account's groups". That's for direction,
> associationAttribute and valueAttribute are for.
>
> For example in OpenLDAP:
>
> <association>
> <ref>ri:group</ref>
> <displayName>LDAP Group
> Membership</displayName>
> <kind>entitlement</kind>
> <intent>ldapGroup</intent>
> <direction>objectToSubject</direction>
>
> <associationAttribute>ri:member</associationAttribute>
> <valueAttribute>ri:dn</valueAttribute>
> </association>
>
> This means:
> 1) midPoint will use "virtual" attribute "ri:group" that you can
> use in mappings (e.g. in roles) to provision to OpenLDAP groups
> 2) direction=objectToSubject: midPoint will put accounts to groups
> (because group membership works this way in LDAP servers and also
> most other systems)
> 3) midPoint will use group's attribute "ri:member" ....
> 4) ... and will put corresponding accounts DN ("ri:dn") attribute
> value there
>
>
> What are you trying to achieve..?
>
> Regards,
> Ivan
>
>
> On 05/03/2016 07:50 AM, Harits Elfahmi wrote:
>> Hello Ivan,
>>
>> Thanks for your suggestion, it works now. But now I want to
>> associate the entitlement to the account. I use the association
>> example from midpoint GitHub:
>>
>> <association>
>> <ref>ri:role_id</ref>
>> <displayName>My Role</displayName>
>> <kind>entitlement</kind>
>> <intent>default</intent>
>> <direction>objectToSubject</direction>
>> <associationAttribute>icfs:uid</associationAttribute>
>> <valueAttribute>ri:role_name</valueAttribute>
>> </association>
>>
>>
>> But it causes an error, and my guess is because of the
>> entitlements and accounts are in different resources. Is it
>> possible to do the association with another resource?
>>
>> Thanks
>>
>> 2016-05-02 14:02 GMT+07:00 Ivan Noris <ivan.noris at evolveum.com
>> <mailto:ivan.noris at evolveum.com>>:
>>
>> Hi Harits,
>>
>> On 05/02/2016 08:17 AM, Harits Elfahmi wrote:
>>> Hello all,
>>>
>>> I'm trying to sync my role data from database table to
>>> midpoint using the GUI. From the docs I get the impression
>>> that the entitlements and accounts originated from single
>>> resource, but since DatabaseTableConnector connect to a
>>> certain table, I think I need to make another resource to
>>> store entitlement data. What I don't get is:
>>>
>>> - In Schema Handling what's the attribute I use in *target*?
>>> Is it *$role/name*? I can't find the reference in the docs
>>
>> Instead of $user you would use $focus. (It would work for
>> users as well.)
>>
>>> - In Synchronization, what's the appropriate reaction? I
>>> can't find *add role* reaction in the dropdown list
>>
>> No, that's connected to the bug you discovered earlier. The
>> proper action is addFocus.
>> <handlerUri>http://midpoint.evolveum.com/xml/ns/public/model/action-3#addFocus</handlerUri>
>>
>> In order to synchronize resource objects to anything else
>> than users, the following must be added to synchronization
>> settings (I don't know if the wizard supports it):
>>
>> ...
>> <objectSynchronization>
>> <name>role sync</name>
>>
>> <objectClass>ri:AccountObjectClass</objectClass><!-- DB Table
>> connector supports only accounts -->
>> <kind>account</kind>
>> <intent>default</intent>
>> <focusType>*c:RoleType*</focusType>
>> <enabled>true</enabled>
>> <correlation>
>> ...
>> </correlation>
>> ...
>>
>> This means that the object will be corelated with Roles, not
>> Users (which is default). In correlation expression you will
>> search for Roles and not Users. If the correlation
>> expressions returns zero results, unmatched situation will
>> occur and action (e.g. addFocus) will be executed. Everything
>> is the same as for users. Just use $focus instead of $user in
>> the inbound mappings.
>>
>> See some of our Generic Synchronization samples such as
>> https://github.com/Evolveum/midpoint/blob/master/samples/resources/opendj/opendj-resource-genericsync.xml
>> (it's OpenDJ, not DB Table, but you will see the things I
>> mentioned).
>>
>> Also see
>> https://wiki.evolveum.com/display/midPoint/Generic+Synchronization
>>
>> Regards,
>> Ivan
>>
>>>
>>> Is it possible to do this? Or do I need to manually add
>>> roles to midpoint? Please help.
>>>
>>> Thanks
>>>
>>> --
>>> Cheers,
>>> *
>>> *
>>> *Harits* Elfahmi
>>>
>>>
>>> _______________________________________________
>>> midPoint mailing list
>>> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>> --
>> Ing. Ivan Noris
>> Senior Identity Management Engineer & IDM Architect
>> evolveum.com <http://evolveum.com> evolveum.com/blog/ <http://evolveum.com/blog/>
>> ___________________________________________________
>> "Semper ID(e)M Vix."
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>>
>>
>>
>> --
>> Cheers,
>> *
>> *
>> *Harits* Elfahmi
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>
> --
> Ing. Ivan Noris
> Senior Identity Management Engineer & IDM Architect
> evolveum.com <http://evolveum.com> evolveum.com/blog/ <http://evolveum.com/blog/>
> ___________________________________________________
> "Semper ID(e)M Vix."
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
>
>
> --
> Cheers,
> *
> *
> *Harits* Elfahmi
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
--
Ing. Ivan Noris
Senior Identity Management Engineer & IDM Architect
evolveum.com evolveum.com/blog/
___________________________________________________
"Semper ID(e)M Vix."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20160503/bcb8cc51/attachment.htm>
More information about the midPoint
mailing list