re: alternative "isCallerInRole" implementation/model

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

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