Re: [xacml-comment] Public Comment

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

nurmamat wrote:
> Hello Mr Anderson:
> 
>    Mr Chen zhao and I are in the same lab; we are
> very thankful to your precious advice, I would like to confirm what you 
> said in your last E_mail and ask some more question,
> 
> you said 
> 
>>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."
> 
> How can The Role Assignment Authority use XACML to do this? Do you mean there is 
> a Policy Information Point using XACML to provide information about Role
> attributes of a User? Can they use XACML or it is out of the scope of XACML? 

Yes, there is a Policy Information Point that generates policies
regarding which users are allowed to hold which roles.  When the Role
Assignment Authority receives a request to assign a role to a given
user, its PEP sends a request to a PDP (possibly the same PDP that
resource access requests are sent to) of the form 'Is Subject A,
Resource role="X", Action "AssignRole"' permitted?

This is within the scope of XACML because it is a request for permission
to "access" a particular role "resource".

Note that in these requests, the "role" Attribute is an Attribute of the
resource rather than an Attribute of the Subject.

> 
> You wrote
> 
>>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.
> 
> I think the word "is the user..." should be "if the user...".

That is correct; I mis-typed.

> my last question and most important one is that if we can introduce Role 
> as the parallel entity with Subject(User), Resource and Action not just a subject
> attributes. if so most components of RBAC model can be solved using XACML.

I'm not sure I understand.  Are you suggesting have Subject, Resource,
Action, Environment, and Role as the "classes" of Attributes?  I don't
think that is a solution, and it is not supported by XACML 1.0, 1.1, or 2.0.

But XACML can allow a given Attribute, such as "role", to be treated as
a Resource Attribute in some queries and policies and as a Subject
Attribute in others.  And an Attribute Authority can have its own set of
XACML policies that are different from the policies used directly by the
user's application.

Please send another e-mail if anything is not clear.  I am happy to try
answering questions.

Anne

> ======= 2005-04-11 20:34:08 You Wrote£º=======
> 
> 
>>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
>>
> 
> 
> = = = = = = = = = = = = = = = = = = = =
> Best Regards
>  				
> 
> ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡nurmamat
> ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2005-04-13
> ---------------------------------------
> Department of Information Science
> Peking University
> Beijing, 100871
> CHINA 
> E_mail:    nur@is.pku.edu.cn
> ----------------------------------------

-- 
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