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: [xacml-comment] Public Comment

On 19 May, comment-form@oasis-open.org writes: [xacml-comment] Public Comment
 > i understand that if user request permission _other than
 > permission for role_ then your model works good.
 > I mean a case if application needs to determine that user
 > granted a role. The real life cases include:
 > 1) J2EE application invokes method isCallerInRole() which is
 > standard J2EE way for application-based access control.
 > RBAC model implies role hierarchy for this.
 > 2) If application needs entitlement information (say, for UI
 > customization). For example, show or not show UI
 > controls depending of what user is entitled to
 > 3) If application needs to determine what role(s) user is
 > graned - for audit, monitoring or other purposes.

Thanks for this explanation.  Now I think I understand what you
are looking for.

When you ask "isCallerInRole(X)", you are basically treating X as
a resource, as in "Does caller have privileges associated with
role X".  I think you could model this in XACML RBAC as follows.

In each Permission Policy Set, where role is "&role-value;X", add
a policy of the following form (or equivalent predicate or
MatchId).  The policy creation tool could do this automatically.

<Policy PolicyId="has:role" PCA="permit-overrides">
<Rule Effect="Permit">
   <Condition FunctionId="and">
      <Apply FunctionId="anyURI-is-in">
          <AttributeValue DataType="anyURI">&role-value;X</AttributeValue>
          <ResourceAttributeDesignator AttributeId="&role;" DataType="anyURI"/>
      <Apply FunctionId="string-is-in">
          <AttributeValue DataType="string">hasPrivilegesOfRole</AttributeValue>
          <ActionAttributeDesignator AttributeId="action-id" DataType="string"/>

Now, to ask whether "Aleksey" has role "&role;employee", submit
the following request:

     <Subject>subject-id = "Aleksey"</Subject>
     <Resource>&role; = "&role-value;employee</Resource>
     <Action>action-id = "hasPrivilegesOfRole</Action>

This request should follow the hierarchical role chaining and
give the correct result.
[Let me know if you need to have this written out in full XACML
XML syntax]

I haven't thought too much about this, so let me know if you see
anything wrong with it.

Thanks for the question.  It stimulated some interesting thinking
on my part.  It may be worth adding this stuff to the XACML
Profile for RBAC.

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

Note: When an application calls "isCallerInRole", the application is
then taking on the functions of the access control system.  In
the case of associating certain options on a web page with a
role, the application has those options (resources) associated
with the role name, rather than asking the access control system
whether the caller has access to each resource in turn.

In the case of auditing of role assignments, this should probably
not be done by the application, but by the AttributeAuthority or
as part of the PDP decision making itself.  The application, or
the PEP, might want to audit that the caller got access to a
particular resource.

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