Re: [xacml-comment] Public Comment

[Anne Anderson <Anne.Anderson@Sun.COM>]

Hi Chen Zhao,

Chen Zhao wrote:
> I think it is not appropriate express Separation of Duty(SoD) using
> XACML. Separation of Duty means that the security administrator must
> not assign two (or more) mutually exclusive roles to one single user.
> And dynamic SoD means that one single user can activate two mutually
> exclusive roles in once session. Howerver, in the XACML Profile for
> RBAC, static SoD policy can not be expressed because XACML profile for
> RBAC can not control user role assignment. It said,

I think you meant to say that "dynamic SoD means that one single user 
can NOT activate two mutually exclusive roles in one session."

The XACML Profile for RBAC does not handle user role assignment, but 
XACML itself can be used to prevent the assignment of incompatible roles 
by a Role Assignment Authority.  This is discussed in the profile.

The primary problem, as I see it, is that for the XACML model, the roles 
a user needs to have must be known prior to evaluation of a policy.  In 
the case of static role assignments, a Context Handler can simply 
request all role attributes for the given user, and supply these as part 
of the Request Context.  The Role Assignment Authority that made those 
assignments in the first place could have used XACML to ensure that no 
incompatible roles were assigned to the same user.  In the case of 
dynamic role assignments, however, it is not until a request to access a 
given resource is made that the role needed for that particular access 
is known (in general).  The roles can't be assigned ahead of time, 
because a single user might be authorized to hold either of two 
incompatible roles, just not in the same session.

One solution for this, not completely thought out, is to use the XACML 
Target elements to select only those policies that apply to a particular 
resource and action, and to use the role attributes only in the 
Condition part of a policy.  The Context Handler, when asked for the 
value of a role Attribute, would submit a request to the Role Assignment 
Authority for that specific role.  The Role Assignment Authority would 
return the role if the user already has it for that session, and would 
activate the role and return it is the user does not already have it and 
it does not conflict with roles the user already has activated for the 
current session.

Such interactions between a Context Handler, Role Assignment Authority, 
and the "session" are outside the scope of XACML itself, but it would 
certainly be possible to specify a model where this type of interaction 
is done in a standard way.

Anne

>    The assignment of various role attributes to users and the enabling
> of those attributes within a session are outside the scope of the
> XACML PDP.
> 
> In fact, the XACML profle for RBAC defines dynamic SoD. It gives
> expression to that once one user activated two (or more) mutually
> exclusive roles, then each request from user will be denied. This
> interpretation may be some different with the definition of dynamic
> SoD since in XACML profile for RBAC mutually exclusive roles can be
> activated in a single session synchronously.
> 
> I think that SoD policy helps security administrator to manage
> privilege, does not bring into play during access decision process. So
> I think SoD should be outside the scope of the XACML PDP. It is more
> better to enforce SoD policy by XACML PEP.
> 
> Is that correct?
> 
> On Apr 6, 2005 10:21 PM, Anne Anderson <Anne.Anderson@sun.com> wrote:
> 
>>The XACML Profile for Role Based Access Control (RBAC) Version 1.0:
>>   * Committee Draft 01, 13 February 2004
>>         o Specification Document:
>>http://docs.oasis-open.org/xacml/cd-xacml-rbac-profile-01.pdf
>>
>>attempted to address Separation of Duty.  You might want to look at that.
>>
>>Some users did not feel it handled certain dynamic Separation of Duty
>>cases, and, although the solutions proposed by the users did not fit the
>>XACML model, we did not have time to fully evaluate this for XACML 2.0
>>so we removed the entire section.  The issue was a desire on the part of
>>some users to link granting access to a given resource with the granting
>>of a role related to that resource, and doing that linkage through XACML
>>itself.
>>
>>Comments welcomed.
>>
>>Anne
>>
>>comment-form@oasis-open.org wrote:
>>
>>>Comment from: nur@is.pku.edu.cn
>>>
>>>Dear Sir/Madam:
>>>
>>>
>>>
>>>I am doing some research on RBAC model in XML based security framework, and read all specification of XACML. You provide the definition
>>>
>>>of core RBAC and hierarchy RBAC profile of XACML.
>>>
>>>now I am wondering if there is a possiblity of providing definition of separation of duty(static and dynamic), role cardinality in XACML.
>>>
>>>In my opinion, using current standard to do so is
>>>
>>>somehow difficult.
>>>
>>>I am eager to know your opinion about this problem.
>>>
>>>           thank you!
>>
>>--
>>Anne H. Anderson             Email: Anne.Anderson@Sun.COM
>>Sun Microsystems Laboratories
>>1 Network Drive,UBUR02-311     Tel: 781/442-0928
>>Burlington, MA 01803-0902 USA  Fax: 781/442-1692
>>
>>
> 
> 
> 

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