[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: role based authorization -> dynacl module?


On 04/24/2018 04:28 PM, Shawn McKinney wrote:
>> On Apr 20, 2018, at 6:45 AM, Daniel Tröder
>> <troeder@univention.de> wrote:
>> 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.
> I applaud your decision to not reinvent the wheel but have doubts
> about using ACL’s to accomplish (more later)
>> On Apr 20, 2018, at 6:45 AM, Daniel Tröder
>> <troeder@univention.de> wrote:
>> 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).
> Classic RBAC scenario for sure.  Nice job using a standards-based
> approach btw.
Thanks. I wasn't completely... "complete" - about our project. So in
the interest of disclosure: ;)
The product is not new, but exists for some years now
(https://www.univention.com/products/ucsschool/). It is completely
open source and free as in beer (except support ofc).
The LDAP tree is replicated from the master to >=1 LDAP slave per
school. All of a schools LDAP objects are in a ou=.. subtree.
For security reasons the replication to the LDAP servers in the school
slaves is "selective": only global (above ou=..) objects and their own
OU subtree is replicated to each slave. With the exception of user
objects, which can "belong" to multiple schools (OUs) by having them
listed in a "school" attribute (and their groups as well). The ACLs
are written so that user objects and their references (groups) can
also be replicated to those "additional" OUs.
There are three hard coded roles (staff, student, teacher) and the
ACLs are getting really hard to maintain (for example
As we want to be able to add more roles without having an ACL
explosion and customers are asking for ways to query the LDAP for
"role@school", we are now investigating new approaches to authorization.

>> On Apr 20, 2018, at 6:45 AM, Daniel Tröder
>> <troeder@univention.de> wrote:
>> 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 → ...
> Why use ACL’s for fine-grained authZ?
> It’s drawbacks, - Not standard / LDAPv3 server lock-in (might not
> be a problem for you)
Our main product is a Linux distribution. UCS@school is kind of an
addon. An LDAP server has been until now the right answer for the
multitude of services that can be installed in a Linux distribution.

> - difficult to maintain and test (complex)

> To determine if necessary another question - how are your
> applications interacting with the directory.  Are they connecting
> using LDAPv3 operations (like search and bind), or is there are
> higher level abstraction in place, (like mod_authnz_ldap)?
There's both: a Python based API that abstracts LDAP objects as Python
objects, but there are a lot of services that query the LDAP directly
- not to mention all the 3rd party software from ISVs.

>> On Apr 20, 2018, at 6:45 AM, Daniel Tröder
>> <troeder@univention.de> wrote:
>> 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?
> There are many ways to achieve RBAC using LDAP.  Typically these
> other methods will use a library that gets imbedded into your
> application to use for the security checks. That way the directory
> ACL’s remain simple, and the bits corresponding to the policy live
> inside of objects that are stored within it, not in metadata for
> its config.
That'd be much simpler to maintain... and faster to extend. But as I
wrote above, not an option.

On the positive side: I do like that authorization is as near to the
data as possible. If the database makes both authentication and
authorization, I won't have to worry about anyone coming between my
code and the data, just because I forgot a firewall setting.


Attachment: signature.asc
Description: OpenPGP digital signature