You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@syncope.apache.org by Manfredo Hopp <mh...@gmail.com> on 2015/11/20 16:53:52 UTC
db resorce propagations
Hi, changing memberships of an account assigned to db resource doesnt
result in propagation.
It should be possible to update an account's attribute (eg reflecting
memberships) just as with LDAPMemberShipPropagation action class for LDAP
resources.
Regards Manfredo
Re: db resorce propagations
Posted by Manfredo Hopp <mh...@gmail.com>.
2015-11-23 4:47 GMT-03:00 Francesco Chicchiriccò <il...@apache.org>:
> On 20/11/2015 16:53, Manfredo Hopp wrote:
>
>> Hi, changing memberships of an account assigned to db resource doesnt
>> result in propagation.
>>
>> It should be possible to update an account's attribute (eg reflecting
>> memberships) just as with LDAPMemberShipPropagation action class for LDAP
>> resources.
>>
>
> The "membership" (e.g. the fact that an user is member of a role) concept
> is not part of the entities managed at framework-level by ConnId.
>
> The LDAP and AD connectors supports this feature via a non-standard
> special attribute ("ldapGroups") to be sent along with user's data, which
> is expected to contain the DN of groups (provisioned by roles in Syncope)
> such user belongs to.
>
> Based on this non-standard feature, LDAPMembershipPropagationActions [1]
> and LDAPMembershipSyncActions [2] utilities are provided, which
> transparently handle the "ldapGroups" management, and works OOTB for most
> cases.
>
> You are instead working with "db resource" - which should be using the
> Scripted SQL connector (the other db-related connector, db-table, can only
> manage users, so it can't really be the case); such connector is extremely
> powerful, in the sense that gives complete control of data exchange with
> Syncope, via Groovy scripts.
>
>
I was referring to db-table resources indeed.
What I try to achieve is updating an accounts (users) attribute that
reflects the memberships of this user.
Example: user has role A (membership id 1) and role B (id 2) and user
attribute "memberships", so propagation of user account should result in
attribute { name:memberships, value: [[A, 1], [B, 2]]} through a resource
action like LDAP's that updates this attribute (NO group attributes
involved) .
Regards
> This also means that there cannot be anything similar to "ldapGroups"
> implemented by default, but also gives you the power to introduce such
> management ("scriptedSQLGroups"?) on your own Groovy scripts; naturally,
> you will also need to create something similar to [1] and [2] to act as
> counterparts on Syncope-side.
>
> Regards.
>
> [1]
> https://github.com/apache/syncope/blob/1_2_X/core/src/main/java/org/apache/syncope/core/propagation/impl/LDAPMembershipPropagationActions.java
> [2]
> https://github.com/apache/syncope/blob/1_2_X/core/src/main/java/org/apache/syncope/core/sync/impl/LDAPMembershipSyncActions.java
>
> --
> Francesco Chicchiriccò
>
> Tirasa - Open Source Excellence
> http://www.tirasa.net/
>
> Involved at The Apache Software Foundation:
> member, Syncope PMC chair, Cocoon PMC, Olingo PMC
> http://people.apache.org/~ilgrosso/
>
>
>
Re: db resorce propagations
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 20/11/2015 16:53, Manfredo Hopp wrote:
> Hi, changing memberships of an account assigned to db resource doesnt
> result in propagation.
>
> It should be possible to update an account's attribute (eg reflecting
> memberships) just as with LDAPMemberShipPropagation action class for
> LDAP resources.
The "membership" (e.g. the fact that an user is member of a role)
concept is not part of the entities managed at framework-level by ConnId.
The LDAP and AD connectors supports this feature via a non-standard
special attribute ("ldapGroups") to be sent along with user's data,
which is expected to contain the DN of groups (provisioned by roles in
Syncope) such user belongs to.
Based on this non-standard feature, LDAPMembershipPropagationActions [1]
and LDAPMembershipSyncActions [2] utilities are provided, which
transparently handle the "ldapGroups" management, and works OOTB for
most cases.
You are instead working with "db resource" - which should be using the
Scripted SQL connector (the other db-related connector, db-table, can
only manage users, so it can't really be the case); such connector is
extremely powerful, in the sense that gives complete control of data
exchange with Syncope, via Groovy scripts.
This also means that there cannot be anything similar to "ldapGroups"
implemented by default, but also gives you the power to introduce such
management ("scriptedSQLGroups"?) on your own Groovy scripts; naturally,
you will also need to create something similar to [1] and [2] to act as
counterparts on Syncope-side.
Regards.
[1]
https://github.com/apache/syncope/blob/1_2_X/core/src/main/java/org/apache/syncope/core/propagation/impl/LDAPMembershipPropagationActions.java
[2]
https://github.com/apache/syncope/blob/1_2_X/core/src/main/java/org/apache/syncope/core/sync/impl/LDAPMembershipSyncActions.java
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC
http://people.apache.org/~ilgrosso/