[midPoint] Sync Entitlements to Role Object with DatabaseTableConnector
Radovan Semancik
radovan.semancik at evolveum.com
Tue May 3 17:48:18 CEST 2016
Hi Jason,
The DatabaseTable is one of the original Sun connectors and it is ripe
for rewrite. E.g. it has obviously originated for use with Sun IDM
(Waveset) where schema was a secondary thing and account was the only
object class. Now midPoint really relies on a good schema and we support
many object classes. The connector code is difficult to salvage. In
addition to that the code is CDDL-licensed which is quite a big
cultural, philosophical and psychological obstacle for us :-) So we do
not have any plans for any substantial development of the DatabaseTable
connector. We would like to rewrite it completely. Actually, I have even
started the rewrite some time ago
(https://github.com/Evolveum/connector-dbtable). But then the plans for
the project for which it was intended changed which means that our
priorities also changed ...
Although representation of multi-value attributes in the relational data
model is not always straightforward I think we can figure out something
when it eventually comes to the connector rewrite. In the meantime the
scripted DB connector is probably your best option.
--
Radovan Semancik
Software Architect
evolveum.com
On 05/03/2016 04:39 PM, Jason Everling wrote:
> "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
> <mailto: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
>> <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 <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
>
>
>
>
>
> 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.
>
>
> _______________________________________________
> 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/20160503/948118b3/attachment.htm>
More information about the midPoint
mailing list