Hi All,
I'd like to open a discussion about a certain implementation. I would open a 
new issue but I would be sure about the requirements.
What I'm going to ask is a little bit hard to explain. I apologize in advance 
for the length.

Yesterday I closed the issue SYNCOPE-7 about the propagation of role and 
membership attributes.
At the moment you can map role/membership attributes to propagate 
role/membership information towards a specific external resource as is for 
normal user attributes.

Role attribute propagation usefulness:
###########################
Think about an external resource where group memberships are identified by a 
specific user attribute value.
May be, an attribute "groups" could be used to specify all  the membership of 
an user.
Probably, integrating this resource someone could be interested into create 
memberships on external resource just assigning roles on syncope.

Now, this is feasible just performing two steps:
1. specifying a role attribute valued with the identifier of the corresponding 
remote role;
2. providing a resource schema mapping for this role attribute.

During propagation (user create or update), all the retrieved values of the 
attribute specified above will be propagated as a multi-value user attribute as 
specified by the resource schema mapping.
###########################

Membership attribute propagation usefulness:
###########################
Syncope membership is the association between a user and a role. Each 
membership could have one or more membership attributes.
A membership attribute is an attribute that is owned by a user because it is 
associated to a certain role.

For example: I have the attribute "ASF Id" because I have the role "ASF 
committer" .

The usefulness to propagate these type of attributes is obvious ....
###########################

The behavior described above has been implemented yet with the issue SYNCOPE-7.
The problem is: what should be the behavior during synchronization?

The possible implementations could be:
1. I could ignore role/membership attribute mappings during synchronization 
(this is the current implementation ---> no issue to open)
2. I can try to synchronize these information also:
        a. Role attribute mappings could be used to assign syncope roles 
dynamically during synchronization
        b. Membership attribute mappings could be synchronized but
                b.1. Memberships must exist
                b.2. if mapped attributes are owned by more than one 
membership, then all such memberships will receive the same values because 
there is no way to know which membership should own a specific value.

Please, let me have some considerations about.

Sorry again for this rant.

Regards,
F.

Reply via email to