> "> authorizations granted to roles can propagate to their sub roles
> > (you may not always want propagation to preserve least privilege)."
sorry about not being precise with terminology. by generalization
(specialization) i was referring to a more general (specialized
respectively) role in the hierarchy.
e.g.,
Employee
Programmer
Java-programmer
Employee is the most generalized, Java-programmer is the most
specific. Direction with which authorizations propagate (up or down)
depends on how you draw the hierarchy. Propagation should go from
Employee to Programmer to Java-programmer (meaning more generic roles
are usually less privileged).
With the "non propagation issue" i was referring to situations where
you may not wanto authorizations you grant to a role to be propagated
to their subroles.
For instance, in a hierarchy which has
Doctor
Doctor-on-duty
you may want some authorizations you grant to Doctor not to propagate
to Doctor-on-duty.
The least privilege principle I was referring to states that subjects
should operate with the minimum set of privileges needed to perform
their task. If you propagate everything to the specialized roles they
can collect more privileges than they need.
except from a paper:
"Roles allow a user to sign on with the least privilege required for
the particular task she needs to perform. Users authorized to
powerful roles do not need to exercise them until those privileges are
actually needed. This minimizes the danger of damage due to
inadvertent errors, Trojan Horses, or intruders masquerading as
legitimate users."
> "> In such a context authorization propagation when dealing with
> > roles can
> > have an additional aspect: if a user is authorized to
> > activate a role s/he
> > can also activate roles that are generalization of it."
what i meant is, for instance, that in a hierarchy like
Employee
Programmer
Java-programmer
if you authorize Alice to activate Java-programmer, then Alice is
implicitely authorized to activate also Employee and Programmer, which
she can choose to adopt instead of the more specific to restrict the
set of privileges she will be having (it is not always nice to have
many privileges for the same reasons why it is not nice to work as
"root" when not needed)
i've noticed somebody posted Sandhu's work on the list (he has most
probably covered these aspects).
-p