Re: XACML and RBAC. Forwarded message from Gerald Brose.

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

1. Standard "role" attribute"

Gerald Brose makes a case for our defining a standard subject
"role" attribute.  He has persuaded me that this is a good idea.
Our interchange is attached.

Here is a concrete proposal:
Add following to Appendix B.5 "Subject attributes":

  This identifier indicates a role associated with the subject.
  Values of this attribute SHOULD be of type
  "http://www.w3.org/2001/XMLSchema#anyURI";.

    urn:oasis:names:tc:xacml:2.0:subject:role

2. Standardize "RBAC Profile"

I would also like to move our RBAC Profile
(http://www.oasis-open.org/committees/download.php/2405/wd-xacml-rbac-profile-01.doc)
to Committee Draft status.  As of the last meetings with the NIST
RBAC people, the only objections were that we should add a
section on administrative policies.  The spec already has a basic
section on administrative policies (i.e. have the role-assigning
or role-enabling entity use its own XACML policies).  I believe
anything more elaborate depends on the resolution of our XACML
2.0 administration of policies issues.

Any objections to putting discussion of the status of the RBAC
profile on the agenda for the 22nd, and, if no objections,
scheduling a Committee Draft vote for Feb 5?

-Anne

--- Begin Message ---

• From: Gerald Brose <gerald.brose@xtradyne.com>
• To: Anne.Anderson@Sun.COM
• Date: Mon, 19 Jan 2004 09:14:57 +0100

Anne,

thanks for your prompt reply. Yes, I do think there is a place
for a standard role attribute. Please see below.

Anne Anderson wrote:
>  > I have waded trough parts of the mailing list archives and the
>  > online resources, including the latest draft for XACML 2.0. I
>  > have one simple question: why is there no standard SubjectAttribute
>  > "role" in the new drafts (as in your RBAC profile), plus a
>  > matching function "is-member"?
>  >
>  > IMHO, role membership is obviously a subject attribute and I
>  > believe that a single attribute and a matching function to test
>  > a subject for role membership would be sufficient to build
>  > even hierarchical role systems. (PDPs could simply assign this
>  > attribute for indirect role members.)
>  > 
>  > Am I missing something here that keeps the TC from simply adopting
>  > roles in this minimal, pragmatic manner? I do know I can extend
>  > XACML myself, but I believe RBAC is now so much accepted that it
>  > might be included in the standard on the same grounds as, say,
>  > key-info.
> 
> We have not discussed this in the XACML TC or with the NIST RBAC
> team, but here is my opinion.  My guess is that others have come
> to the same conclusion, and so it has simply not been raised as
> an issue.
> 
>   It is easy to use URIs to create unique values for roles, but I
>   think an organization is likely to want to have more than one
>   category of role, such as "Employee-Status-Role",
>   "SunLabs-Role", "SW-Organization-Role",
>   "Standards-Organization-Role", etc.  These could be handled via
>   some sort of hierarchy under a common "role" attribute, but by
>   using a flat structure with primitive datatype values, it is
>   possible to use AttributeDesignators rather than XPath
>   expressions within AttributeSelectors.  It would be possible to
>   embed the hierarchy within the values for a single "role"
>   attribute by flattening the namespace, but again, it seems
>   simpler to let groups define their own role categories.

Are you saying there could be different kinds of roles in a single
organization (as opposed to different values for that attribute)?
I would not expect that to happen, and have not seen that anywhere
in the literature (of course that does not mean it does not exist
or could not be used.)

The main problem with RBAC adoption in practice seems to be "role
engineering", i.e. finding the right role names to model the
security policies. Using different kinds/types roles would severely
aggravate that problem. The main attractiveness of roles is there
supposed simplicity and the intuitivenss of the metaphor, all that
would be lost. (I believe the NIST RBAC folks would second that).

>   It is trivial to define and use a new attribute in XACML, so
>   long as the data type is one of those supported.

Sure. I would still ask that a new standard attribute type role
is added to the subject attributes in section B.5. There are two
reasons for asking that:

1) It is done in other security systems and common:

   The CORBA security service, e.g, has had a security attribute
   "role" (in addition to AccessId, PrimaryGroupId, GroupId,
   AttributeSet, Clearance, Capability) all along. A role
   attribute is very much akin to these other subject attributes.

2) Having a standard role attribute rather than policy-specific
   role notions makes policy interoperation across domains easier.

   Simply because you need not establish that you mean the same
   with the different role attributes used in the different
   policies. By analogy, we also don't have different access IDs

>  So it is easy
>   for each role-using group to define its own unique URI for its
>   own set of roles.  Likewise, the group can create its own
>   values for those role attributes.  These group-specific role
>   values could be URIs, if there is a need to provide for
>   uncoordinated role definitions, but so long as the group
>   provides centralized definitions, the values could be simple
>   strings.

Absolutely, I just don't see any value in differentiating between
different role notions (and URIs). I haven't seen this used any-
where.

>   Alternatively, Sun Labs could define its own role AttributeId:
>   "http://research.sun.com/role";, and define its two values with
>   respect to that particular role attribute.
> 
> Does this satisfy your requirements?  Do you still think there is
> a place for a single, standard "role" attribute?

I have implemented a non-standard role solution myself in a
similar pattern as in your RBAC profile, but that got me
thinking that RBAC adoption in XACML would be simpler in the
general case with a standard attribute. As I said, I would
not envision any non-standard roles to be widely used.

Cheers and thanks, Gerald.
-- 
Dr. Gerald Brose                        mailto:brose@xtradyne.com
Xtradyne Technologies                     http://www.xtradyne.com
Schoenhauser Allee 6-7,                  Phone: +49-30-440 306-27
D-10119 Berlin, Germany                  Fax  : +49-30-440 306-78

--- 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