[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: status of dynamic separation of duty in XACML RBAC
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]