Re: role based authorization -> dynacl module?

[Michael Ströder <michael@stroeder.com>]

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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature