Hello,
On 04/22/2018 05:57 AM, Howard Chu wrote:
Daniel Tröder wrote:
Hello everyone,
I am in the process of implementing a role concept via ACLs and hope for a hint so that I don't invent the wheel a second time.
Specifically, it is about identity management for schools. A user (object) can have several roles in multiple schools. Permissions on other LDAP objects can thus differ depending on the role(s) the user and the object have in the same school(s).
For example, a user could have been assigned the following roles that are scattered over several schools: → "Teacher" in school 1 → "School admin" in school 2 → "Parent" in school 3 → both "Teacher" and "Staff" in school 4
ACLs should now be defined accordingly, e.g. → the role "teacher" at school X can reset the password for the role "student" at school X → the role "teacher" at school X *cannot* reset the password for the role "student" of school Y → the role "school administrator" at school X can reset the password for the roles "student" and "teacher" at school X → ...
So far I have not seen any way to map such a construct via groups or sets without including a separate ACL for each group, which is a performance issue. Is there another way to map the role concept besides implementing an own dynacl module?
I think a dynacl module is your only choice. Most people miss the difference between roles and groups - group membership applies all the time. Once you're a member of a group, the privileges of that group are omnipresent.
OK - good to know we might be on the right track.
Whereas, membership in a role grants you these privileges *only for as long as you assert that role* and adopting a role is a temporary, bounded activity.
So you need, at the least, in an LDAP context, an exop that says "assume role X" and the corresponding "drop role X". Without these two primitives, you don't actually have roles or role-based access control. LDAP's spec for proxy authorization might be sufficient for this purpose.
I read the rfc4370. It's very cool - it'd allow us to implement real roles. But AFAICS it requires the clients to actively request its use though. As our IDMs LDAP is accessible to 3rd parties, I don't think that will work for us.
In the meantime my colleague has written a (proof of concept) dynacl module "rolecmp". The proposed solution works with two attributes: * school: list of schools a user "belongs to" e.g. ['schoolA', 'SchoolB'] * role: list of "role:school" pairs describing the role(s) an object has, when accessing other objects of the same school, e.g.: ['teacher:schoolA', 'student:SchoolB', 'teacher:schoolZ', 'administrator:schoolZ']
The dynacl module "rolecmp" allows ACLs like this:
attrs=krb5...,samba...,userPassword,pw... by dynacl/rolecmp/teacher,schooladmin=student write by dynacl/rolecmp/schooladmin=teacher write
The dynacl module does implicitly compare the school part (behind the colon) of the "role" attribute of both the accessing and the accessed object. The accessing objects roles are all of those on the left side of the equality sign. The accessed objects role is on the right side.
In the above ACL, access would be allowed for example: * by a user with ['teacher:X', 'student:Y'] to a user with ['student:X', 'administrator:Z'], because 'teacher:X' and 'student:X' match. * by a user with ['teacher:Z', 'schooladmin:Y'] to a user with ['student:X', 'teacher:Y'], because 'schooladmin:Y' and 'teacher:Y' match.
Access would be denied for example: * by ['teacher:X', 'student:Y'] to ['student:Y'] * by ['schooladmin:X'] to ['student:Y', 'teacher:Z']
While the connection does not change from user to role, the authorization process decides only by compare roles (at places)... this can still be called role based authorization, right?
We like his PoC a lot: * It is very easy to read (esp. compared with sets). * It is easy to extend: we/our customers will be able to create new roles without touching the dynacl module! * In tests it was at least not slower than our current set-based ACLs.
Can you think of a conceptual or technical problem with this solution?
Greetings Daniel
PS: as a bonus, this will allow 3rd parties to do queries like this: * Is user 'uid=foo' a student (anywhere)? --> '(&(uid=foo)(role=student:*))'. * Is user 'uid=bar' a teacher at school "X"? --> '(&(uid=bar)(role=teacher:X))'.
We'll also need a role:school definition like 'administrator:*' to express "is an administrator in all schools". Not sure about using the asterisk here though...