Hello,
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 https://github.com/univention/ucs-school/blob/4.3/ucs-school-ldap-acls-maste...). 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)
Definitively.
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.
Greetings Daniel