[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: re: alternative "isCallerInRole" implementation/model. Forwardedmessage from Aleksey Studnev.
The most recent response from Aleksey Studnev on the alternative RBAC method. -Anne
--- Begin Message ---
- From: Aleksey Studnev <Aleksey_Studnev@exigengroup.com>
- To: Anne.Anderson@Sun.COM
- Date: Fri, 11 Jun 2004 10:36:35 +0400
Dear Anne,
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
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).
So application and PEP does not need to know "which specific (non-hierarchical) roles are required for access to a given resource/action"
Is it clear description?
Regards,
Aleksey
Anne Anderson <Anne.Anderson@Sun.COM> 06/10/2004 10:19 PM
Anne.Anderson@Sun.COM
Aleksey Studnev <Aleksey_Studnev@exigengroup.com> XACML COMMENT <xacml-comment@lists.oasis-open.org> re: alternative "isCallerInRole" implementation/model
Aleksey,
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.
Anne
On 1 June, Aleksey Studnev writes:
> Anne,
>
> this is absolutely correct.
>
> Regards,
> Aleksey
>
> On 1 June, Anne Anderson writes:
> > From: Anne Anderson <Anne.Anderson@Sun.COM>
> > To: Aleksey Studnev <Aleksey_Studnev@exigengroup.com>
> > Cc: Anne.Anderson@Sun.COM, XACML COMMENT <xacml-comment@lists.oasis-open.org>
> > Subject: [xacml-comment] Re: Fw: alternative "isCallerInRole" implementation
> > Date: Tue, 01 Jun 2004 13:00:55 -0400
> >
> > Aleksey,
> >
> > 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
--
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
--- End Message ---
-- 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]