Re: role based authorization -> dynacl module?

[Daniel Tröder <troeder@univention.de>]

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...


-- 
Daniel Tröder
Open Source Software Engineer
http://www.univention.de