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