MHonArc v2.5.0b2 -->
xacml message
[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 ---
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
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]