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.