Minutes from 9 June 2003 XACML RBAC meeting

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

Submitted on behalf of Rick Kuhn, who took the minutes and wrote
them up.  Thanks, Rick!

Minutes of XACML Focus Group Meeting, 9 June 2003

Topic: Review of XACML RBAC Profile

Present:
  Rick Kuhn <kuhn@nist.gov>
  David Ferraiolo <david.ferraiolo@nist.gov>
  Ramaswamy (Mouli) Chandramouli <mouli@nist.gov>
  Anne Anderson, Sun Microsystems
  Krishna Sankar, Cisco Systems
  Tim Bouma, RCMP

Action Items
============
[NIST] work on a hierarchical RBAC proposal for XACML
[Anne A.]  investigate 1) section on administrative policy, 2) approach to 
returning sets of permissions rather than yes/no decision


Discussion of RBAC standard vs. XACML

Anne Anderson led the meeting, suggesting that we walk through
the draft standard with the aim of determining which portions
would be backed up by XACML.

Tim Bouma introduced his work on RBAC within a large distributed
government system being developed for Canadian law enforcement
and related agencies. The resulting model, Governance Based
Access Control, extends RBAC.

Anne initiated the review of the RBAC standard with section 6,
Core RBAC, explaining that the AddUser function is not part of
the XACML RBAC profile. An XACML policy would be used by the
entity implementing AddUser to determine which subjects are
allowed to add a user, however. Anne explained the concept of a
policy decision point (PDP) within XACML. Given a set of
policies, a PDP uses information in a decision request to
evaluate against policies and return a grant or deny decision. A
request comes from a Policy Enforcement Point (PEP), which
intercepts requests to access resources. The PEP does not have an
internal representation of the security policy, but packages
requests for the PDP. The PDP sends the result of a decision back
to the PEP, which is responsible for enforcing the decision.

Tim asked about the situation where there are multiple policies
for a user. Anne said that XACML supports the concept of multiple
subjects in making a request. This may be done in a Java
application, if it is not known whether an applet can be
trusted. XACML can identify types of users categories, which are
like roles. Subject categories are extensible, and can identify
other types of subject information e.g., IP address or other
relevant info.

Discussion of taxonomy/ number of profiles for XACML/RBAC

Mouli said he will give feedback on the XACML profile compared
with XML definitions for RBAC, and suggested that there could be
a taxonomy of profiles for XACML, one for each of the four levels
in the RBAC standard. This would relieve users of the need to
pick various parts of the XACML profile depending on the level of
the RBAC standard chosen.

Anne reported her experience with developing the XACML RBAC
profile and proposed having one profile so that users can migrate
to a hierarchical model without rewriting policy.  Mouli said
that NIST could focus on a profile for hierarchical RBAC.  An
action item was agreed upon, in which NIST will work on a
hierarchical RBAC proposal.

Discussion of Check Access function

Anne noted that the only piece of the API that XACML directly
implements is the Check Access function.  The rest is done by
calls to XACML modules.  Also discussed was the need for
separation between the administrative model and operational
aspects.  CheckAccess uses relationships set up in the model, so
this is different for basic RBAC vs. hierarchical.

Discussion of Administrative policies and functions

Tim commented on the add/delete user functions.  This is outside
of the RBAC model, and defined by external agencies for his
system.  There is a need to know what roles have which particular
polices enforced against them, and to know how the Check access
function makes a decision. There is a need to define policies
consistently across entities.  XACML is a perfect vehicle for
standard expansion of policies, enabling them to be shared
reliably and legally across agencies.

There was also discussion of flexibility in assigning user
attributes.  There is a need to decide whether policy should
include administrative or only check access in the XACML
specification. Anne proposed that we may want to add a section on
administrative policies.  The "RolePermissions",
"UserPermissions", and "SessionPermissions" APIs would require
different options than currently in XACML.  These require
returning a set of permissions, which is not a trivial process.
There is some work on this area with respect to web services, for
web services policy language. This is focused on a definition of
returning a set of attributes, not specifically permissions.  A
specification for this can be downloaded from
http://www.oasis-open.org/committees/download.php/2562/wd-xacml-webservices-profile-01.doc

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