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. [1] https://www.ae-dir.com/docs.html#roles
smime.p7s
Description: S/MIME Cryptographic Signature
