Minutes from XACML Focus Group on RBAC, 24 April 2003

Minutes of XACML Focus Group Meeting 24 April 2003
Version: 1.3
Updated: 03/04/24 (yy/mm/dd)

Topic:  XACML as a language for RBAC Policies

Present:
  NIST:

Rick Kuhn <>

David Ferraiolo <>

Ramaswamy (Mouli)

Chandramouli <>
  XACML:

Tim Moses, Entrust

Hal Lockhart, BEA

Carlisle Adams, Entrust

Anne Anderson, Sun (minute taker)

Bob Griffin, Entrust

Simon Godik, OverXeer

Michiharu Kudo, IBM

Polar Humenn, Syracuse University

ACTION ITEM: Interested NIST guests to join XACML TC so that they can

participate in the e-mail discussions.

Agenda:
 -Background on XACML specification, who is using XACML?
 -Quick overview of XACML.  When can we get it?
 -XACML TC mechanics
 -Where do we go from here
References:
 -Proposed ANSI RBAC standard:

http://csrc.nist.gov/rbac/rbac-std-ncits.pdf
 -Initial XACML straw-man proposal:

http://lists.oasis-open.org/archives/xacml/200304/msg00032.html

Note: Mouli has implemented parts of RBAC in XML, so he is

familiar with XML, but the other NIST participants are not so

familiar.

1. Background on XACML Specification and XACML TC

Carlisle Adams gave brief history of the OASIS XACML TC and

specification.  XACML Version 1.0 was approved as an OASIS

standard on February 18.  There are two open source

implementations [see TC web site at

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml

for more information].

BEA has intentions to use XACML in future products.  Entrust

is using an early version of XACML in their "getAccess"

product, with plans to move to the 1.0 version as soon as

possible.  Sun product groups are exploring use of XACML.

Others are planning to use as a transfer format.  It is a very

new standard, and few companies are willing to make public

product commitments this soon, but there are clearly numerous

companies working on making use of XACML.

The XACML TC is currently exploring use of XACML for privacy

and web service policy language applications via XACML

profiles.  Many members of the XACML TC are also members of

the OASIS SSTC, which works on SAML.

2. Overview of XACML

Hal Lockhart gave an overview of the XACML language and its

constructs.  Authorization decision model is shared by SAML

and XACML, based on the ISO IETF model.  It is comprised of

o Attribute Authorities: Entities that provide information

about subjects, resources, etc.  Attributes of the

environment in which an Authorization Decision Request is

made (e.g. time of day) can also be supplied.

o Authentication Authorities: (added by SAML) states which

individuals have authenticated and how.

o Policy Administration Points (PAP): generate policies (may be

multiple PAPs and multiple policies)

o Policy Enforcement Points (PEP): generate Authorization

Decision Requests, send them to a PDP, receive

Authorization Decision and enforce the decision.  If the

Decision includes "Obligations", then the PEP is

responsible for carrying those out.

o Policy Decision Point (PDP): evaluate policies in the

context of a specific Authorization Decision Request and

return an Authorization Decision.  Authorization Decision

may include optional "Obligations", which are attributes

representing information to be acted upon by the PEP.

Scope of the XACML is to define the language for expressing

Authorization Decision Requests to (XACML Request Context) and

Authorization Decision outputs from (XACML Response Context)

the PDP and for expressing policies (XACML Policy and

PolicySet) for input to the PDP.

In an XACML Request Context, attributes are grouped according

to the entity to which they apply: attributes of various

Subjects involved in making the access request, attributes of

the Resource being accessed, attributes of the Action to be

performed on the Resource, and attributes of the Environment

within which the access request is being made.  An XACML

Request Context is a "potentially imaginary" construct that

represents all these attributes of the access request.  The

Request and Response Contexts provide an abstraction that

insulates XACML from any specific environment or input/output

protocol.

XACML supports federated policies (e.g. local policies,

divisional policies, organizational policies), efficient

location of applicable policies, multiple subjects involved in

a particular access (e.g. both the requester and the receiver

of some information to be accessed).  XACML can be used alone,

with its native Request and Response Contexts, with SAML

Authorization Decision Request/Response, or with other

request/response protocols/formats.  XACML has submitted a

proposal to SAML to include native XACML Request/Response

Contexts in SAML 2.0.  SAML 1.0 Authorization Decision

Requests can also be mapped to an XACML Request Context, and

an XACML Response Context can be mapped (partially) to a SAML

Authorization Decision.

How does the PDP know which policy to apply?  A PDP may be

configured with an initial policy or it may be configured to

look for applicable policies in some repository.  Any given

policy (PolicySet) may include any number of other policies

(PolicySet or Policy), either inline or by reference.

The first stage of policy evaluation is to look at the Target

of the Policy.  If the Target predicates are TRUE given the

particular decision request, then the remainder of the policy

is evaluated.  XACML "Combining Algorithms" handle conflict

resolution between the results of various policies that may be

part of a PolicySet.  XACML defines several useful Combining

Algorithms, and can be extended to support additional ones.

XACML does not deal with the assignment, activation, storage,

or retrieval of attributes (such as roles).  Existing XACML

open source implementations can handle the policies expressed

in the straw-man XACML RBAC proposal

(http://lists.oasis-open.org/archives/xacml/200304/msg00032.html).

An implementation must be extended to know how to retrieve

attributes from appropriate locations.

In order to implement the proposed ANSI RBAC standard model,

what is needed in addition to an XACML PDP implementation

(already available) would be (in one view):

o Attribute Finder Modules that know where to look for

activated role attributes and can return their values when

requested based on an attribute identifier and values for

other relevant attributes such as subject identity, data

type, etc.

o Policy Retrieval Modules that know where to look for

policies and can retrieve them based on an identifier key.

o Policy Enforcement Points: these are application specific,

but must intercept requests to access controlled resources,

make Authorization Decision Requests to the XACML PDP, and

enforce the PDP decision.

o Role Activation Entity that activates roles and makes them

available to the Attribute Finder Modules.  Applications

would invoke a Role Activation Entity when activation of a

role is requested or required.  A Role Activation Entity

would have its own Policy Enforcement Point through which

it would have requests to activate certain attributes

checked against role activation policies.

o Policy Administration Point to create appropriate policies

and store them in appropriate repositories.

3. XACML TC Mechanics

XACML TC meets via conference call (currently every other

week).  Alternate weeks are devoted to "Focus Groups" that

address particular topics.  Most work is accomplished on the

XACML mailing list, with meetings being used to make decisions

(also lots of discussion!).  Occasionally, depending on the

level of work required, Face-to-Face meetings are held.

Any member of OASIS can join the XACML TC.  Any member of the

TC can submit e-mail to the XACML TC mailing list.  The XACML

TC mailing list archives are open to the public

(http://lists.oasis-open.org/archives/xacml/)

The first step in producing a new OASIS standard is for the TC

to draft a specification.  The TC then votes (2/3 majority

required) to make the draft a "Committee Specification".  Some

specification remain at this stage.  A TC may choose to

present a Committee Specification to the general OASIS

membership for approval as an OASIS Standard.  It takes about

two months from the time a Committee Specification is

submitted to OASIS until public review and voting are

completed and the specification becomes an OASIS Standard.

4. Q & A

Q: Would XACML complement the proposed ANSI RBAC standard, or

would it be an alternative?

A: XACML can implement part of the standard, but much of the

standard is APIs for Role Activation Authorities, Policy

Administration Points, etc.  XACML can express all the aspects

of the standard related to policy expression and policy

evaluation.

Q: Who would use the results of such a Profile?  Who would

implement it?

A: Most of the XACML members are vendors.  RBAC is of interest

to many of our customers, especially government.  XACML vendor

members are interested in providing products that our

customers want.  The NIST guests said that over a billion

dollars in procurements is associated with the ANSI RBAC

standard.

5. Status of the proposed ANSI RBAC standard

RBAC draft (http://csrc.nist.gov/rbac/rbac-std-ncits.pdf) was

put out for public comment starting April 18.  Comment period

closes June 18.  Anyone can submit comments.  NIST guests

suggested that XACML TC members might be interested in

commenting that it is important to agree on a stable RBAC

standard and not continue arguing about additional

features.

Once approved, there might be a revision of the standard after

several years, but NIST is not planning on further extensions

to the RBAC standard, such as APIs.

6. OT: OMG effort to define interfaces that use XACML

Polar says he is starting an initiative at OMG to come up with

an MDA (model-driven architecture) with a set of CORBA

interfaces extending the Resource Access Decision standard

(the admin interface for dealing with and combining policies)

to use XACML.  One such interface is "access allowed", which

takes a resource, a set of attributes, and other contextual

information.  MDA needs to define how this is expressed using

an XACML Request Context.  OMG does not define a language for

expressing the policies, just the interfaces for

administration and evaluation of policies.  One of the

interfaces would a factory that would create a policy

interface based on a description language.  E.g. take a tag

"XACML" and a description of a policy in XACML, and create an

object behind the Policy interface in the RAD.

7. Where do we go from here?

Goal: Define an XACML Profile for use with RBAC.

Method: Create an XACML subcommittee to define how XACML

meshes with the proposed ANSI standard and to define an XACML

profile.

Plan: Discussion of RBAC and XACML, the strawman, etc. to take

place on the XACML TC mailing list.  Out of this discussion

will come a plan for a follow on phone conference.

--
Anne H. Anderson
Email: 
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311
Tel: 781/442-0928
Burlington, MA 01803-0902 USA
Fax: 781/442-1692