OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: alternative "isCallerInRole" implementation/model


Aleksey Studnev wrote:
> Anne,
> 
> i did not understand what you mean by "Before the
> "urn:sea:role:is-granted" function is called, the
> <SubjectAttributeDesignator> will have already been evaluated."
> 
> Match function is exacuted _when_ SubjectAttributeDesignator is 
> evaluating, not before or after.

I'm sorry, but that is wrong.  In XACML, function arguments are 
evaluated before they are passed to the function itself.

> It returns result (effectively boolean) which says if caller is in role.
> 
> About the ContextHandler will not know... - you are absolutely true,
> but this is not needed. Context handler only knows of user attributes 
> and roles are not that attributes.Match funtion can determine what role 
> is activated what is not.

I do not know what "roles are not that attributes" means. 
"urn:...:role" is the AttributeId of an XACML Subject Attribute whose 
value is the URI associated with a specific role.  To me, this means a 
role is a user attribute.

You could perhaps define a Boolean function that would take as arguments 
two values, return TRUE if the role value in the first argument is held 
by the subject identified in the second argument:

   <Apply FunctionId="does-subject-have-role">
    <AttributeValue DataType="#anyURI"> some role URI </AttributeValue>
    <SubjectAttributeDesignator AttributeId="subject-id"/>
   </Apply>

This requires a function that has side-effects in a way that I don't 
think any of our existing functions have.

The current XACML Profile for Role Based Access Control requires no new 
functions, no new special Attributes that have to be "understood" by the 
PDP, and no other extensions to XACML.  At this point, I plan to publish 
the Profile with an added option for handling an action "hasRole" (or 
similar name) as I outlined in 
http://lists.oasis-open.org/archives/xacml-comment/200405/msg00009.html 
but do not plan to make any further substantive changes.

You might want to develop a profile using your alternative approach and 
submit it to the XACML TC for consideration.

Anne

> Regards,
> Aleksey
> 
> 
> *Anne Anderson <Anne.Anderson@Sun.COM>*
> 
> 13.07.2004 16:12 AST
> 
> ------------------------------------------------------------------------
> Please respond to Anne.Anderson@Sun.COM
> ------------------------------------------------------------------------
> 	
> To
> 	
> Aleksey Studnev <Aleksey_Studnev@exigengroup.com>
> 
> cc
> 	
> XACML COMMENT <xacml-comment@lists.oasis-open.org>, XACML TC 
> <xacml@lists.oasis-open.org>
> 
> bcc
> 	
> 
> Subject
> 	
> re: alternative "isCallerInRole" implementation/model
> 	
> 
> 
> On 11 June, Aleksey Studnev writes: re: alternative "isCallerInRole" 
> implementation/model
>  > the main question is "But how did the PEP know that role
>  > "Employee" was the one to ask for? ".  The solution i used is
>  > to use special function "role-is-granted"
>  >
>  > <SubjectMatch MatchId="urn:sea:role:is-granted">
>  >    <AttributeValue
>  >        DataType="http://www.w3.org/2001/XMLSchema#anyURI";>
>  >          urn:xacml:sea:policy:role:Admin</AttributeValue>
>  >    <SubjectAttributeDesignator
>  >        AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role"
>  >        DataType="http://www.w3.org/2001/XMLSchema#anyURI"/>
>  > </SubjectMatch>
>  >
>  > and this function delegates this check to PEP which in turn
>  > asks for RolePermission.
>  >
>  > Complete sequence in runtime is:
>  > 1) Application asks PEP for access resource
>  > 2) PEP asks PDP for the decision about resource access. It
>  >    makes request with subject, resource attrs, action
> 
> e.g. subject-id == "Aleksey"
> 
>  > 3) PDP finds policy for the resource and iterate over xacml
>  >    Rules. In the rule it finds SubjectMatch as above
>  > 4) PDP invokes role:is-granted function. If role is active for
>  >    the subject, it returns true. If it is not active, function
>  >    delegates this call to PEP by requesting role
>  >    activation. In this sense PDP works here as application on
>  >    step 1. Now the sequense will again recursively start from
>  >    step 1 (role now is resource).
> 
> XACML functions do not work that way.  Before the
> "urn:sea:role:is-granted" function is called, the
> <SubjectAttributeDesignator> will have already been evaluated.
> Functions do not get "raw" arguments - they get evaluated
> arguments.
> 
> The PDP will ask its ContextHandler for
> AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role", which
> effectively asks for all "role" Attributes associated with a
> subject-id of "Aleksey".  The ContextHandler will not know that
> it needs to check to see if resource-id
> "urn:xacml:sea:policy:role:Admin" action-id "is-granted" to
> subject-id="Aleksey".
> 
> Anne
> 
>  > So application and PEP does not need to know "which specific
>  > (non-hierarchical) roles are required for access to a given
>  > resource/action"
>  >
>  > On 10 June, Anne Anderson writes:
>  >
>  > > Regarding
>  > > http://lists.oasis-open.org/archives/xacml-comment/200406/msg00000.html
>  > >
>  > > Step 1 in the model you describe might indeed be used by an
>  > > Attribute Authority, and could be used to answer questions like
>  > > "isSubjectInRole(<role>,<subject-id>).  [The XACML Profile for
>  > > RBAC can also be used to answer this question, as I showed in
>  > > 
> http://lists.oasis-open.org/archives/xacml-comment/200405/msg00009.html]
>  > >
>  > > I do not think the model you describe is a good model for role
>  > > based access control, however.
>  > >
>  > > 1) It requires the PEP to know which specific (non-hierarchical)
>  > >    roles are required for access to a given resource/action.
>  > >    This embeds policy into the application (PEP), while the goal
>  > >    of policy-based access control is to allow policy to be
>  > >    separate from the application.
>  > >
>  > > 2) It puts the responsibility for determining role hierarchies
>  > >    into the hands of the Role Assignment/Activation Point (RAP),
>  > >    and not in the hands of the resource's Policy Administration
>  > >    Point (PAP).  My model of RBAC is intended to allow these two
>  > >    functions to be separate: the RAP knows which direct roles to
>  > >    assign to which specific people, the other PAP knows which
>  > >    direct roles are associated with which access rights and is
>  > >    free to arrange roles hierarchically to better manage these
>  > >    associations.
>  > >
>  > > As an example, using your model, assume subject "Aleksey" has
>  > > role "Manager", which is senior to role "Employee".  Assume role
>  > > "Employee" is required to "read" file "/a/b/c".
>  > >
>  > > When "Aleksey" attempts to "read" file "/a/b/c", the PEP will
>  > > intercept this request.  In your model, the PEP must first ask
>  > > the PDP whether "Aleksey" has the role "Employee".
>  > >
>  > > But how did the PEP know that role "Employee" was the one to ask
>  > > for?  It must be because the PEP has that information stored: "if
>  > > user asks to 'read' file 'a/b/c', the user must have role
>  > > 'Employee'".  And that means policy is embedded into the
>  > > application.  If the Policy Administration Point later decides
>  > > that an "Employee" can't 'read' file '/a/b/c', but only a
>  > > "Financial Officer", then the application itself must be changed,
>  > > and not just the XACML Policy.
>  > >
>  > > The XACML Profile for Role Based Access Control (newest draft at
>  > > 
> http://www.oasis-open.org/committees/download.php/6806/wd-xacml-rbac-profile-02.1.pdf
>  > > )
>  > > is intended to separate policy from the application.  The
>  > > application (and PEP) only needs to know which direct roles are
>  > > enabled for a Subject, and which resource/action are being
>  > > attempted by the Subject.  Even the direct role information can
>  > > be off-loaded to the PDP.
>  > >
>  > > On 1 June, Aleksey Studnev writes:
>  > > > this is absolutely correct.
>  > > >
>  > > > On 1 June, Anne Anderson writes:
>  > > >  > I am still trying to understand your RBAC model.  I believe use
>  > > >  > of RBAC in your model requires two steps:
>  > > >  >
>  > > >  > 1) Ask the PDP if the Subject has a given role enabled.  There is
>  > > >  >    a collection of policies that answers this question, and this
>  > > >  >    collection supports hierarchies of roles.
>  > > >  >
>  > > >  > 2) Using the given role now as a Subject Attribute, ask if the
>  > > >  >    Subject has permission to do some particular action on some
>  > > >  >    particular resource.  The collection of policies for answering
>  > > >  >    this question is not hierarchical, so you have to ask the
>  > > >  >    question using the right role value.
>  > > >  >
>  > > >  > Is this correct?
> --
> 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             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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]