XACML 3.0 New Features and Standardization Status

Prepared for ITU-T by

Hal LockhartOracleSeptember 17, 2009

XACML Current Status XACML 2.0 OASIS Standard – Feb 2005 ITU-T Recommendation X.1142 – Jun 2006 XACML 3.0 In progress

Core & base profiles recently completed Public Review Administration/delegation {New} Hierarchical resource {Enhanced} Multiple resource {Enhanced} SAML {Enhanced} Digital Signature, Privacy, RBAC

XSPA Profile submitted for OASIS Standard Additional profiles under development

Obligation families, Export Compliance, Policy Distribution, Metadata, WS-XACML, Intellectual Property Control

Request Context Schema Generalization

Triggered by need to add “delegate” for reduction Eliminate <Subject>, <Environment>, <Resource> &

<Action> Elements Everything carried in <Attributes> Element URNs used to identify categories

XACML 2.0 Subject categories New URNs for Environment, Resource, Action & Delegate

Categories Generally upwardly compatible

Attribute selectors may require manual conversion Policy & Context Schemas combined

XACML 2.0 Request Context

<Request …> <Subject> <Attribute AttributeId=“ … subject-category” …> <AttributeValue> … access-subject</AttributeValue> </Attribute> <Attribute> AttributeId=“ … subject-id” …> <AttributeValue>John Smith</AttributeValue> </Attribute> <Attribute> AttributeId=“ … group” …> <AttributeValue>Engineer</AttributeValue> </Attribute> </Subject> <Resource> <Attribute> AttributeId=“ … resource-id” …> <AttributeValue>http://www.example.com/</AttributeValue> </Attribute> </Resource>…</Request>

XACML 3.0 Request Context

<Request …> <Attributes Category=“ … access-subject”> <Attribute> AttributeId=“ … subject-id” …> <AttributeValue>John Smith</AttributeValue> </Attribute> <Attribute> AttributeId=“ … group” …> <AttributeValue>Engineer</AttributeValue> </Attribute> </Attributes> < Attributes Category=“ … resource”> <Attribute> AttributeId=“ … resource-id” …> <AttributeValue>http://www.example.com/</AttributeValue> </Attribute> </Attributes>…</Request>

XACML 3.0 Administration/Delegation

Two primary use cases “HR-Admins can create policies concerning

the Payroll servers” “Jack can approve expenses while Mary is on

vacation” Backward compatible Defined as an optional Profile Policies can contain Issuer Policies can be Access or Admin Admin policies enable policy creation

Policy Evaluation

1. Select potentially applicable policies by Target matching

2. For each Policy evaluate Rules and combine

Target Match Evaluate condition Return Effect and associated Obligations

3. For each Policy Set combine policy results

4. Return Effect and Obligations

Policy Evaluation with Admin Policies

1. Select potentially applicable policies by Target matching

2. For each Policy evaluate Rules and combine Target Match Evaluate condition Return Effect and associated Obligations

3. For every un-trusted policy Find an applicable Admin policy which authorizes the Issuer Repeat until a chain to a trusted policy is found Discard unauthorized policies

4. For each Policy Set combine policy results

5. Return Effect and Obligations

Fine Points of Reduction

Access and Administrative policies are matched against the situation, not each other

Current vs. Historic attribute mode Indeterminate results must be propagated

for combining Maximum delegation depth Obligations in Administrative policies

apply to access decision

Obligation Families

Allows Obligations to be grouped in families with the same properties

Specific Obligations semantics still undefined Timing – before, after, with access or any Exclusive - Fallback = true or false Sequential

Ordered = true or false Repetitive = true or false Failure Mode = fail fast, continue or atomic

Work in process

New Combining Algorithms

More rational handling of Indeterminate Same algorithms for rule and policy combining Indeterminate are classified by possible effect Example: for deny overrides, if Indeterminate

rule or policy could only result in Permit & there is at least one Permit, result is Permit

New algorithms are mandatory to implement Old algs are present, but not recommended

Other new features

Multiple decisions in a single request, varying any attribute category (just Resource in 2.0)

Advice – like Obligations, but can be ignored if not understood by PEP

New XPath 2.0 functions New time duration functions Policy distribution protocol Decision request protocol based on WS-Trust Metadata profile Authorization API, Attribute Manifest File

Authorization API

XACML 2.0 Specifies Policy language evaluation semantics XML format for policy interchange Abstract format for inputs and outputs,

expressed in XML Protocol for remote requests using XML input

& output format XACML 2.0 does not specify

API for requesting policy decision

Authorization API Benefits

Needed for call to local PDP Local PDP required for low latency

calls Inefficient to serialize data to and from

XML XML form not required by the standard

Also useful to have standard API for remote requests Common code to build message

API General Characteristics Java initially, C++ and perhaps others to

follow Modeled on XACML Request/Response

Contexts Use XACML datatypes – in format natural to

language Mostly to be used by infrastructure

components Occasionally application may need to provide data Infrastructure could be Container, Aspects, tool-

generated code, etc.

Why not Java Authorization/JSR 115?

Java Authorization (with or w/o JSR 115) based on Permissions

Passive enforcement by container is a good idea

Limitations to use of XACML features No convenient, standard way to provide XACML

inputs No method to return outputs, e.g. Obligations,

missing Attributes New Resource type requires definition of new

permissions class (recompile)

API Overview Methods to build (and access) Request

Context Methods to process Response Context “decide” method to invoke PDP

Single or bulk decisions “whatIsAllowed” method to obtain allowed

alternatives Operates in the context of some scope Creates invokes a series of decisions Returns allowed alternatives within scope

Other convenience methods

The Input Attributes Problem

XACML Policies operate on data provided

Only PDP sees/evaluates policies What attributes should be provided? Where can attributes be obtained

from? How can the proper instance value

be obtained?

Attribute Manifest File

File in XML format identifies attributes to be added to Request Context

Name of Attribute, Issuer, datatype, location, access method, other attribute to use as key

Not all fields may be present Three usecases:

PDP advertizes required attributes PIPs are configured to add attributes to Request

Context Policy authoring tools use attribute name &

format

Multiple PIP’s – Enhancing Request Context

LDAP

Application

PEP

PDP

AMF

AMF

AMF

P

I

P

P

I

P

P

I

P

ReqCtx

ReqCtx

ReqCtx

OVD

DB

SAML

Multiple PIP’s – Reacting to Missing Attributes

LDAP

Application

PEP

PDP

AMF

AMF

AMF

P

I

P

P

I

P

P

I

P

RespCtxMiss Attr

OVD

DB

SAML

RespCtxMiss Attr

RespCtxMiss Attr

API and AMF Standardization Approach Contributed to OASIS XACML TC in July 2009

Intent is to standardize Interoperable components Open Source Project started to develop

implementations API

Mate with open source XACML impl Implement remote client Mate with JAAC

AMF Deployment time access methods

More info: http://www.openliberty.org/wiki/index.php/Main_Page#OpenAz

Projected Status - Spring 2010

Only XSPA Profile likely to reach OASIS Standard

Core & 1st set of Profiles will reach Committee Specification Need Implementations

TC may adopt XACML 2.0 Approved Errata