[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: re: alternative "isCallerInRole" implementation
On 24 May, Aleksey Studnev writes: Re: Fw: undefined
> i followed the model of roles in your profile which assumes that "role"
> attributes of Subject are permissions
> for the resource.
> Following this, when PEP makes execution of the request it does not store
> any attributes for roles in subject - it rather
> request them as permission for specific resource. In this extent my
> example follows your model defined in profile.
> So far the sequence will be:
> 1) Submit request
> <Request>
> <Subject>subject-id = AttributeValue "Anne"</Subject>
> <Resource>role = AttributeValue "Employee"</Resource>
> <Action>action-id = AttributeValue "enable"</Action>
> </Request>
> 2) PDP looks in policy and finds:
> <Policy>
> <Target>
> ResourceAttributeDesignator "role" = AttributeValue "Employee"
> </Target>
> <Rule Effect="Permit">
> <Target>
> SubjectAttributeDesignator
> "urn:oasis:names:xacml:2.0:subject:subject-id" = AttributeValue "Kill
> Bill"
> ActionAttributeDesignator "action-id" = AttributeValue "enable"
> </Target>
> </Rule>
> <Rule Effect="Permit">
> <Target>
> SubjectAttributeDesignator "role-id" == AttributeValue "Manager"
> ActionAttributeDesignator "action-id" == AttributeValue "grant"
> </Target>
> </Rule>
> </Policy>
> 3) Policy checks for "urn:oasis:names:xacml:2.0:subject:subject-id" =
> AttributeValue "Kill Bill" and this does not match.
So far, right.
> 4) Policy checks for "role-id" == AttributeValue "Manager" in Subject
> which is done throught permission check
> (is role granted)
And this does not match, so the second <Rule> is not applicable.
The PDP now stops and returns "NotApplicable" because all
<Policy> elements have been evaluated, and none was applicable.
The PDP does not "grant" the "Manager" role-id. The PDP does not
"do" actions - they are just strings that it interprets according
to its matching rules. The PDP does not understand the word
"grant" and does not "grant" that role for any further
evaluation.
You could possibly implement a PDP that did understand "grant",
but that is not currently part of the XACML specification. I
think you would quickly run into problems, however. Your model
seems to be that if the PDP encounters an "action" that matches a
distinguished value "grant", and all other attributes match, then
the Target resource should be effectively substituted for the
original resource in the Request, and evaluation would start
over. For starters, this would require XACML to evaluate <Rule>
elements in a <Policy> where the <Target> of the <Policy> did not
match - XACML currently says do not evaluate a <Policy> if the
<Target> does not match. I think that is only the start of the
problems you will run into.
The XACML TC is working on a model for delegation that might do
something like what you want, but it is a very hard problem.
> 5) Policy finds rules
> <Policy>
> <Target>
> ResourceAttributeDesignator "role" = AttributeValue "Manager"
> </Target>
> <Rule Effect="Permit">
> <Target>
> SubjectAttributeDesignator
> "urn:oasis:names:xacml:2.0:subject:subject-id" = AttributeValue
> "Aleksey"
> ActionAttributeDesignator "action-id" = AttributeValue "enable"
> </Target>
> </Rule>
> <Rule Effect="Permit">
> <Target>
> SubjectAttributeDesignator "role-id" == AttributeValue "Superuser"
> ActionAttributeDesignator "action-id" == AttributeValue "grant"
> </Target>
> </Rule>
> </Policy>
> 6) Policy checks for SubjectAttributeDesignator
> "urn:oasis:names:xacml:2.0:subject:subject-id" = AttributeValue
> "Aleksey" and this does not match
> 7) Policy checks for SubjectAttributeDesignator "role-id" ==
> AttributeValue "Superuser" and this is permission check
> 8) Policy finds rules and they match due to SubjectAttributeDesignator
> urn:oasis:names:xacml:2.0:subject:subject-id" = AttributeValue "Anne"
>
> PEP of course must be implemented in the way that it is aware that role
> attributes in Subject are permissions
> and should be requested.
I don't understand what you mean. The PEP received a request for
"isCallerInRole("Anne","employee"), so it sent the following
request to the PDP:
<Request>
<Subject>..Anne..</Subject>
<Resource>..employee..</Resource>
<Action>..grant..</Action>
</Request>
Is that what you meant by "it is aware that role attributes in
Subject are permissions and should be requested"?
With your set of policies, interpreted according to the XACML
specification, the PEP gets back a response of "NotApplicable".
Anne
> Regards,
> Aleksey
>
>
>
>
> Anne Anderson <Anne.Anderson@Sun.COM>
> 05/21/2004 10:35 PM
> Please respond to
> Anne.Anderson@Sun.COM
>
>
> To
> Aleksey Studnev <Aleksey_Studnev@exigengroup.com>
> cc
> XACML TC <xacml@lists.oasis-open.org>
> Subject
> Re: Fw: undefined
>
>
>
>
>
>
> Your example does not work. What request would I submit in order
> to find out whether isCallerInRole("Anne","employee"), if "Anne"
> has role "Superuser"?
>
> If I submit following:
>
> <Request>
> <Subject>subject-id = AttributeValue "Anne"</Subject>
> <Resource>role = AttributeValue "Employee"</Resource>
> <Action>action-id = AttributeValue "enable"</Action>
> </Request>
>
> I do not get any Rule that returns "Permit".
>
> You seem to be trying to do delegation, where XACML does not yet
> support delegation (we are discussing it).
>
> Anne
>
> On 21 May, Aleksey Studnev writes: Re: Fw: undefined
> > From: Aleksey Studnev <Aleksey_Studnev@exigengroup.com>
> > To: Anne.Anderson@Sun.COM
> > Subject: Re: Fw: undefined
> > Date: Fri, 21 May 2004 18:47:53 +0400
> >
> > Anne,
> >
> > in this sense ("*immediately* issue") we are on the same page. With my
> > proposal you only need
> > to include immedeate roles as well. I will add another role (Superuser
> > which is senior to Manager) to demonstrate that:
> >
> > <PolicySet>
> > <Policy>
> > <Target>
> > ResourceAttributeDesignator "role" = AttributeValue "Superuser"
> > </Target>
> > <Rule Effect="Permit">
> > <Target>
> > SubjectAttributeDesignator
> > "urn:oasis:names:xacml:2.0:subject:subject-id" = AttributeValue "Anne"
> > ActionAttributeDesignator "action-id" = AttributeValue "enable"
> > </Target>
> > </Rule>
> > </Policy>
> >
> > <Policy>
> > <Target>
> > ResourceAttributeDesignator "role" = AttributeValue "Manager"
> > </Target>
> > <Rule Effect="Permit">
> > <Target>
> > SubjectAttributeDesignator
> > "urn:oasis:names:xacml:2.0:subject:subject-id" = AttributeValue
> "Aleksey"
> > ActionAttributeDesignator "action-id" = AttributeValue "enable"
> > </Target>
> > </Rule>
> > <Rule Effect="Permit">
> > <Target>
> > SubjectAttributeDesignator "role-id" == AttributeValue "Superuser"
> > ActionAttributeDesignator "action-id" == AttributeValue "grant"
> > </Target>
> > </Rule>
> > </Policy>
> >
> > <Policy>
> > <Target>
> > ResourceAttributeDesignator "role" = AttributeValue "Employee"
> > </Target>
> > <Rule Effect="Permit">
> > <Target>
> > SubjectAttributeDesignator
> > "urn:oasis:names:xacml:2.0:subject:subject-id" = AttributeValue "Kill
> > Bill"
> > ActionAttributeDesignator "action-id" = AttributeValue "enable"
> > </Target>
> > </Rule>
> > <Rule Effect="Permit">
> > <Target>
> > SubjectAttributeDesignator "role-id" == AttributeValue "Manager"
> > ActionAttributeDesignator "action-id" == AttributeValue "grant"
> > </Target>
> > </Rule>
> > </Policy>
> >
> > </PolicySet>
--
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]