Il 15/11/2013 13:05, Timo Hatakka ha scritto:
Hi!
in current implementation each (user, role) pair is unique. However, because
the membership schema can be extended there would possibility to allow
parallel connections with different membership attribute values. This could
make role management much easier.
Let's take a example:
we have 5 different kind of students S1, .. S5 and each has connection to
one of the departments D1 .. D100. And one student can have more than on
role simultaneously. And we have 10 different kind of Emplyee roles E1..E10
and also these are connected to the departments. And a employees can also be
students simultaneously or also work in more than one department. (Very real
situation for academic world)
We want to express for persons something like:
p1 is S3 student in D45 and S4 student in D56
p2 is S4 student in D1
p3 is E4 employee in D87 and E10 employee in D6 and S1 student in D11
If we expand roles over departments, we will get S1D1,, S1D100 . E10D100 ->
5x100 + 10x100 roles -> 1500 roles and a huge number of thing to maintain.
However, if you could extend your model a little bit, we would success with
15 roles S1..S5, E1..E10. The connection to a department would me expressed
in the membership. So instead of having S4D1 role p2 would have S4(D1) role
which could be implemented by membership(p1, S3, department=D45). Roles and
corresponding departments are coming from HR or student system.
This kind of parametric membership concept could be used for example for
LDAP group memberships.
Motivation to this question can be found for example from
https://wiki.evolveum.com/display/midPoint/Advanced+RBAC / Parametric Roles.
Hi Timo,
I think you can change your view perspective: you can consider to use
roles for department and membership attributes for student/employee types.
In this way you should manage 100 roles "only".
Suggested extension sounds a little bit hard and .... I'm not so sure
about its usefulness.
I think that, quite soon, you will be able to model your
situation/environment simply by using realms (departments), roles
(students and employees) and memberships. Maybe, developments about [1]
have to take into consideration your requirements.
Best regards,
F.
[1] https://issues.apache.org/jira/browse/SYNCOPE-119
--
Fabio Martelli
Tirasa - Open Source Excellence
http://www.tirasa.net/
Apache Syncope PMC
http://people.apache.org/~fmartelli/
