status of dynamic separation of duty in XACML RBAC

[Anne Anderson <Anne.Anderson@sun.com>]

Colleagues,

This question came in off-list, and I thought others might be interested 
in the answer.

> For the implementation of user-role assignment, the context handler
> queries the REA (role enablement authority) for role attribute.  For
> the implementation of the REA, I bulit another context handler and
> another PDP for generating request context (subject id, role, enable)
> and evaluating the request against role assignment policy. If the PDP
> in the REA return "pemit" decision, the context handler in the REA
> will return the role attribute to the requested context hanlder..
>
> However, I am not sure how can I add the "session" entity to support
> dynamic RBAC.  I mean when you activate r1 in the session s1, you can
> perform the permissions that r1 is allowed to invoke in the session
> s1. For the case of dynamic seperation of duty, you can not activate r2
> in the session s1. So how can I implement the "session" entity in the
> XACML model?

There is no completely satisfactory solution for this problem in XACML
RBAC yet, which is why "separation of duty" was removed from the XACML
RBAC Profile.

There are several problems involved:

1. Recording role enablement state

Making enablement of a role dependent on which other roles have been
enabled and on which session id they were granted under means the REA
must record state each time it enables a role.  The state information
must include role enabled, subject id, and session id.  XACML itself is
stateless, so the REA must record this information external to XACML.

Depending on whether the subject can operate under more than one session
id at a time, the session id information might need to be passed as part
of the <Request> from the PEP to the PDP and thus to the REA, or might
be obtained directly from the session manager by the REA.

The REA will also need to know when a user terminates a session under
which a role was previously enabled in order to remove stale entries.
This could be done in various ways: periodic request by the REA to
session manager, event message to REA from session manager, time limits
on role enablement, or, as a partial solution if user can have only one
session at a time, have REA remove entries for any previous session when
a user requests a role for a new session id.

2. Expressing REA policies depending on incompatible roles

Assume problem 1 has been solved, and that the REA can return values for
an Attribute named "currently-enabled-roles" based on subject id and
session id values present in the <Request>.

Have a Deny Rule for each set of incompatible roles {r1, r2, ...}:
   if "requested-role" is in {r1, r2, ...}
   and "currently-enabled-roles" intersect {r1, r2, ...} then Deny.

If it is not an error for a subject to attempt to enable a role the
subject already has enabled, then one rule designed to override the
other rules can state: if "requested-role" is in "current-roles", then
Permit.

Usually there will be requirements for enabling a role other than lack
of role conflicts, so there will probably also need to be Rules that
Permit a given role only if those requirements are met (e.g. "enable
role r1 if time-of-day is between 9-5 AND subject is in
accounting-department") AND if none of the incompatible roles is enabled.

3. Knowing when to request enablement of a role

This is the hard problem.  Assume dynamic role r1 is required for an
action the user has requested, and assume r1 is not currently enabled
for this user.  Assume r1 conflicts with dynamic role r2, which also is
not currently enabled for this user, but which the user is allowed to
enable so long as r1 is not already enabled.

a. If a Rule applying to this request has a <Target> requiring '"role"
includes r1', then the PDP will request values for "role" from the
ContextHandler when this rule is evaluated, but there will be no
information available regarding "r1", or even that "r1" is the value
required.

This is confusing to some people: the <Apply> function clearly includes 
a match against "r1", so why can't the ContextHandler know that is the 
role requested and try to enable it?  The reason is that the arguments 
to the standard XACML functions are Expressions, which may be 
arbitrarily complex.  The arguments to a function must be completely 
evaluated before they are passed to the function (since the function 
does not know how to evaluate arbitrarily complex expressions), and the 
arguments are evaluated completely independently - the evaluation of one 
argument does not have any information about other arguments to the same 
function.  There is no general semantics for an "equals" function and 
its Expression arguments that could "tell" one of its arguments that 
happens to be a <SubjectAttributeDesignator> that it will be matched 
against a value "r1" that is a dynamic role.  When the 
<SubjectAttributeDesignator> Expression that requests the "role" 
Attribute is evaluated, the ContextHandler has no information about how 
the values it obtains will be used: perhaps they will be used as input 
to a "anyURI-bag-size" function, and will not be matched against 
anything at all; or perhaps the value against which the 
<SubjectAttributeDesignator> Expression is matched will be a complex set 
of nested functions and Attrvalueibute references rather than a simple 
<AttributeValue>, and that other argument has not yet been evaluated.

The end result is that the ContextHandler, when it tries to get values 
for the <SubjectAttributeDesignator> with AttributeId "role", does not 
know about any other arguments, so there is nothing to trigger a request 
to enable role "r1" (Seth may well have an explanation for all this that 
is more clear than mine).

So this is not a solution.

b. If the application itself knows that role r1 will be required to do
an action that the user attempts, then the application could first
request "enable role r1" from the REA, and then request the actual
action on the resource.  But most policy writers want the required roles
for a given action to be maintained separately from the application
logic, so this is not a general solution.

c. Rather than using a "role" Attribute, one can use a set of Boolean 
Attributes "can-enable-role-r1", "can-enable-role-r2", ...  When the 
ContextHandler is requested to provide a value for one of these 
Attributes, it can be written to request enablement of the corresponding 
role from the REA, and return the result.  Alternatively, one could 
write a new "enable-role" function, that would take as its argument the 
role value that is needed.  The function returns a Boolean result, 
indicating whether the role has been enabled, and a side effect of the 
function is that the role is enabled if it was not previously and if 
enablement is permitted by the REA.

BUT since these Attributes will have the side effect of actually
enabling the requested roles (assuming no conflicting role is already
enabled), the policies must be designed very carefully.  No <Target> can
use these Attributes, and each Rule that depends on a dynamically
enabled role must be formulated such that the Condition uses an
"ordered-and" with the reference to the "can-enable-role-r*" Attribute 
or the invocation of the "enable-role r*" function placed in the last
<Apply> under the "ordered-and".  Thus, all other conditions will have
been satisfied before the required role will be tested/enabled.

If policies are not designed this way, then a <Target> or <Rule> that is
evaluated before the <Rule> that applies to the actual request might
reference the Attribute "can-enable-role-r2", even though the user's
current request does not actually require enablement of r2.  As a side
effect of this evaluation, r2 will be enabled, and when the later <Rule>
that actually applies to the request and requires r1 is evaluated, r1
will not be enabled because it will conflict with r2, which has already
been enabled.  Thus the user will not get access.

Of course, making policies dependent on such side-effects and on careful
ordering of condition predicates is error-prone, and is definitely not
an ideal solution.  It also does not allow use of Hierarchical RBAC,
which uses "role" Attributes in <Target> elements.

CONCLUSION

So, at least with current proposals, there is no easy or good solution
to the problem of dynamic separation of duty in XACML, although it can
be done.  A clean solution for dynamic separation of duty would be very 
useful if someone is able to contribute one to the TC.

Regards,
Anne
-- 
Anne H. Anderson               Anne.Anderson@sun.com
Sun Microsystems Labs          1-781-442-0928
Burlington, MA USA