TL;DR: When modeling roles one should start from the use-cases.
Howard Chu wrote:
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.
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.
Hmm, probably we mean the same. But I'd like to re-phrase a bit:
Each use-case (the actual work to be done) defines which actor roles are allowed to exercise the use-case. The role can be determined in the simplest case just by simple group membership (e.g. super-power admin role) or by an arbitrary set of (dynamic) conditions.
In Æ-DIR the roles are mainly driven by use-cases and are always limited to a certain "scope", e.g. by relationship of objects to the zone(s) or by service group(s). [1]
For the use-cases affecting LDAP access (data maintenance, data retrieval) set-based ACLs are in effect which are indeed very slow. So a dynacl module would be nice for that. Or a custom LDAP server...
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'd argue that for security reasons the change-role / change-hat action should never be possible without a (re-)authentication. So in Æ-DIR true role separation simply requires a separate user/system account. But that's me.
Ciao, Michael.