[midPoint] Sync Entitlements to Role Object with DatabaseTableConnector
Jason Everling
jeverling at bshp.edu
Tue May 3 16:39:06 CEST 2016
"I hope that the connector support the multivalue attributes."
I could not get multi-value attributes to work in one of our database table
resources. I checked ConnID and OpenICF for related settings and did not
find any. We do though use database views, one of them is actually
read/write so updates are pushed back to the view.
If someone does know how to use multi-value attributes in a database
resources please let me know! If not, eventually I will need to migrate it
to a scripted db resource.
JASON
On Tue, May 3, 2016 at 2:34 AM, Ivan Noris <ivan.noris at evolveum.com> wrote:
> 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>:
>
>> 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>
>> 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>
>>> 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 listmidPoint at lists.evolveum.comhttp://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."
>>>
>>>
>>> _______________________________________________
>>> midPoint mailing list
>>> midPoint at lists.evolveum.com
>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>>
>>>
>>
>>
>> --
>> Cheers,
>>
>> *Harits* Elfahmi
>>
>>
>> _______________________________________________
>> midPoint mailing listmidPoint at lists.evolveum.comhttp://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."
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>>
>
>
> --
> Cheers,
>
> *Harits* Elfahmi
>
>
> _______________________________________________
> midPoint mailing listmidPoint at lists.evolveum.comhttp://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."
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
--
CONFIDENTIALITY NOTICE:
This e-mail together with any attachments is proprietary and confidential;
intended for only the recipient(s) named above and may contain information
that is privileged. You should not retain, copy or use this e-mail or any
attachments for any purpose, or disclose all or any part of the contents to
any person. Any views or opinions expressed in this e-mail are those of the
author and do not represent those of the Baptist School of Health
Professions. If you have received this e-mail in error, or are not the
named recipient(s), you are hereby notified that any review, dissemination,
distribution or copying of this communication is prohibited by the sender
and to do so might constitute a violation of the Electronic Communications
Privacy Act, 18 U.S.C. section 2510-2521. Please immediately notify the
sender and delete this e-mail and any attachments from your computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20160503/4a4584cf/attachment.htm>
More information about the midPoint
mailing list