Minutes from XACML Focus Group on RBAC, 24 April 2003

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

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 <kuhn@nist.gov>
    David Ferraiolo <david.ferraiolo@nist.gov>
    Ramaswamy (Mouli) Chandramouli <mouli@nist.gov>
  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: 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