XACML 2.0 in the Enterprise: Use-Cases and Deployment Challenges

Prateek Mishra, Frank Villavicencio, Rich LevinsonOracle Identity Management Group

02/07/2006 - STA-201

Agenda

•What is XACML?

•XACML Policies

•XACML 2.0 Specification Set

•Sample Policies

•Vocabularies and Applications

•AAPML: A XACML Profile

•Deployment Models

•Challenges

•Conclusions

What is XACML?

• eXtensible Access Control Markup Language

•Provides

—a common language for expressing security policy

—a request / response language to obtain access control decisions

• the request asks whether or not the requesting user (Subject) should be allowed to perform a specific action (Action) on a particular resource (Resource) under a given set of environmental (Environment) conditions

• the response includes a decision whether the request should be allowed (Permit, Deny, Indeterminate or Not Applicable) and obligations associated with the decision

• the data elements of request and response are intimately tied to the expressions in the policy language

XACML Overview

• XACML Policies are contained in a PolicySet

—A Policy is expressed through a set of Rules

—a PolicySet may contain multiple Policies or PolicySets, each of which may evaluate to different access control decisions (XACML uses algorithms to reconcile the decisions each Policy or Rule makes)

• Targets

—A Target is a set of conditions for the Subject, Resource, Action, and Environment that must be met for a PolicySet, Policy, or Rule to apply to a given request

• Attributes

—Attributes are characteristics of the Subject, Resource, Action, or Environment in which the access request is made (attributes may be the username, employment level, the resource to be accessed, etc.)

XACML Rules

•Rules are the atomic elements of Policy decisions – the smallest elements within the XACML Policy structure that render a decision

— Each Rule identifies the set of Subjects, Resources, and Actions that are covered by the Rule – this collection is referred to as the Target

— Each Rule is evaluated in isolation against a decision request (RequestContext) and determines whether or not to allow the Subject to execute the specified Action against the Resource

•The Rule examines the RequestContext to determine if the Subjects, Resources, and Actions match those covered by the Target

•The Rule then evaluates Conditions, which are functional tests against the data elements in the Target and RequestContext

— Each Rule renders a decision based on the evaluation which can be one of: Permit, Deny, Indeterminate, NotApplicable

XACML Request Response Model

•RequestContext is normative structure for submitting a decision request

— RequestContext contains Subject, Resource, Action, and Environment elements

— A Policy is evaluated only in terms of its contents in relation to the RequestContext contents

— Evaluation of the Policy results in an authorization decision: Permit, Deny, Indeterminate, or NotApplicable

•ResponseContext is normative structure for returning an authorization decision

— ResponseContext contains Result element, which contains Decision element plus optional ResourceId, Status, and Obligations elements

XACML RequestContext Example

•The RequestContext contains the inputs that the PDP evaluates against the applicable Policy

<Request xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:os" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >

<Subject>

<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType="xs:string" Issuer="med.example.com">

<AttributeValue>CN=Homer Simpson</AttributeValue>

</Attribute>

</Subject>

<Resource>

<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="http://www.w3.org/2001/XMLSchema#anyURI"/>

<AttributeValue>https://med.example.com/BartSimpsonRecord.jws</AttributeValue>

</Attribute>

</Resource>

<Action>

<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="xs:string">

<AttributeValue>read</AttributeValue>

</Attribute>

</Action>

<Environment/>

</Request>

XACML 2.0 Specifications

•XACML Core Specification:

—“eXtensible Access Control Markup Language (XACML) Version 2.0”

• XACML Resource Support:

—“Multiple resource profile of XACML v2.0”

—“Hierarchical resource profile of XACML v2.0”

—“Privacy policy profile of XACML v2.0”

• XACML Subject Support:

—“Core and hierarchical role based access control (RBAC) profile of XACML v2.0”

• XACML Protocol Support:

—“SAML 2.0 Profile of XACML v2.0” (AuthZ req/rsp, Policy distribution, and Attribute query protocols)

—“XML Digital Signature profile of XACML v2.0”

XACML Strengths

•XACML is a standardized Policy evaluation model that abstracts the major features of modern enterprise access control systems

•New access control areas of focus are regularly emerging and we examine XACML strengths in two of these areas

— Fine-grained authorization

•Enabled by rich Attribute Expression Model

•Selection, Functions, VariableReferences

•Enriched using domain-specific vocabularies

— Control over use of accessed resources

•Enabled by Attribute assignment model of Obligations

XACML Attribute Expression Model 1

•Entity Matching within Rules

•Match, AttributeDesignator, AttributeValue

•Example (is the requested resource the PatientRecords web service?):

<ResourceMatch

MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">

<ResourceAttributeDesignator

AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"

DataType="http://www.w3.org/2001/XMLSchema#anyURI"/>

<AttributeValue

DataType="http://www.w3.org/2001/XMLSchema#anyURI"

>https://med.example.com/PatientRecords.jws</AttributeValue>

</ResourceMatch>

XACML Attribute Expression Model 2

• Functional Expressions in Rules

• Fine-grained authorization enabled with resource attributes

• Function, Subject/ResourceAttributeDesignators, VariableReference

• Example (Is Subject parent-guardian and (by VarRef) is patient under 16):

<Condition>

<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:and">

<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-one-and-only">

<SubjectAttributeDesignator

AttributeId="urn:oasis:names:tc:xacml:2.0:example:attribute:parent-guardian-id"

DataType="http://www.w3.org/2001/XMLSchema#string"/>

</Apply>

<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-one-and-only">

<ResourceAttributeDesignator

AttributeId="urn:oasis:names:tc:xacml:2.0:example:attribute:parent-guardian-id"

DataType="http://www.w3.org/2001/XMLSchema#string"/>

</Apply>

</Apply>

<VariableReference VariableId="17590035"/>

</Apply>

</Condition>

XACML Attribute Expression Model 3

•Variable Definitions - reusable

• Function, Environment/ResoureAttributeSelectors, AttributeValue

• Example (is patient under 16 years old based on date today):<VariableDefinition VariableId="17590035"> <Apply FunctionId="urn:oasis:names:tc:xacml:2.0:function:date-less-or-equal"> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:date-one-and-only"> <EnvironmentAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-date" DataType="http://www.w3.org/2001/XMLSchema#date"/> </Apply> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:date-add-yearMonthDuration"> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:date-one-and-only"> <ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:example:attribute:patientDOB" DataType="http://www.w3.org/2001/XMLSchema#string"/> </Apply> <AttributeValue DataType="http://www.w3.org/TR/2002/WD-xquery-operators-20020816#yearMonthDuration"> <xf:dt-yearMonthDuration>P16Y</xf:dt-yearMonthDuration> </AttributeValue> </Apply> </Apply></VariableDefinition>

XACML Vocabularies and Obligations

•XACML domain-specific vocabularies and constraints can be readily defined with existing XACML 2.0— http://www.fedora.info/

— http://www.fedora.info/download/2.2/userdocs/server/security/XACMLPolicyGuide.htm

— Identity Governance Framework (AAPML)

• http://www.oracle.com/goto/igf

— Specify constants and URIs that describe additional attribute values and matching rules for use in subject, resource, environment, action and obligation containers

•XACML Obligations can be used to direct PEP to enforce specific constraints on requests, such as privacy requirements

XACML Vocabulary Example

•AAPML: Attribute Authority Policy Markup Language

— http://www.oracle.com/technology/tech/standards/idm/igf/pdf/IGF-AAPML-spec-08.pdf

— XACML profile designed to allow owners of “identity-related” data to specify conditions under which information may be used by other applications

— Vocabulary namespace: “urn:aapml:1.0:names”

— AAPML attributes used to constrain Subjects, Resources, Actions, identify Rules, and to specify Obligations that PEP must apply to requests

AAPML Example 1

•Subject constraints: known accessing service, user with authentication attribute

<Subject> <!-- This Subject pertains to the application making the request --> <!-- for a user. The application is known by its service-name, the --> <!-- identifier for which must match a regular expression prefix. --> <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-regexp-match"> <SubjectAttributeDesignator AttributeId="urn:aapml:1.0:names:subject:service-name" DataType="http://www.w3.org/2001/XMLSchema#string"/> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string"> http://www.example.com/marketing/* </AttributeValue> </SubjectMatch> <!-- This subject pertains to the user that is making the request --> <!-- to the application. The user must have authenticated and have --> <!-- a non-null subject:user-auth attribute --> <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-regexp-match"> <SubjectAttributeDesignator AttributeId="urn:aapml:1.0:names:subject:user-auth" DataType="http://www.w3.org/2001/XMLSchema#string"/> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string"> * </AttributeValue> </SubjectMatch></Subject>

AAPML Example 2

•Resource constraints (specific data elements):<Resources> <!-- EmailAddress --> <Resource> <ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <ResourceAttributeDesignator AttributeId="urn:aapml:1.0:names:resource:generic" DataType="http://www.w3.org/2001/XMLSchema#string"/> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string" >EmailAddress</AttributeValue> </ResourceMatch> </Resource> <!-- FirstName --> <Resource> <ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <ResourceAttributeDesignator AttributeId="urn:aapml:1.0:names:resource:generic" DataType="http://www.w3.org/2001/XMLSchema#string"/> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string" >FirstName</AttributeValue> </ResourceMatch> </Resource><!-- LastName --><Resource> ...

AAPML Example 3

•Action and Rule constraints: <Actions>

<Action>

<ActionMatch

MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

<AttributeValue

DataType="http://www.w3.org/2001/XMLSchema#string"

>urn:aapml:1.0:names:action:read</AttributeValue>

<ActionAttributeDesignator

AttributeId="urn:aapml:1.0:names:action"

DataType="http://www.w3.org/2001/XMLSchema#string"/>

</ActionMatch>

</Action>

</Actions>

</Target>

<Rule

RuleId="urn:aapml:1.0:names:rule-id:permit-if-consent-available"

Effect="Permit">

<Description>

Marketing apps can access user information if explicit consent is available.

</Description>

</Rule>

AAPML Example 4

•Obligations:<Obligations> <!-- This is an example obligation that refers to a legal restriction --> <!-- document, referencible at the state government site, which the --> <!-- PEP must notify the requestor is condition for use of the --> <!-- returned data. --> <Obligation ObligationId="urn:aapml:1.0:names:obligation:consent" FulfillOn="Permit"> <AttributeAssignment AttributeId="urn:aapml:1.0:names:obligation:consent:agreement-identifier" DataType="http://www.w3.org/2001/XMLSchema#anyURI" >http://www.state.gov/userdata#PublicGenLaw2005</AttributeAssignment> </Obligation> <!-- This obligation says that any data returned from this request --> <!-- must not be cached, which the PDP must notify the requestor --> <Obligation ObligationId="urn:aapml:1.0:names:obligation:do-not-cache" FulfillOn="Permit"/> <!-- This obligation says that any data returned from this request --> <!-- must not be propagated, which the PDP must notify the requestor --> <Obligation ObligationId="urn:aapml:1.0:names:obligation:do-not-propagate" FulfillOn="Permit"/></Obligations>

Agenda

XACML Enterprise Deployment

XACML Actors

•PAP – Policy Administration Point

— The (logical) system entity that creates a policy or policy set

•PEP – Policy Enforcement Point

— The (logical) system entity that performs access control, by making decision requests and enforcing authorization decisions

•PDP – Policy Decision Point

— The (logical) system entity that evaluates applicable policy and renders an authorization decision

•PIP – Policy Information Point

— The (logical) system entity that acts as a source of attribute values

— Attributes describing the subject (user), resource, environment (context)

Actor Relationships

Extended PDP

Enterprise Requirements 1

•Policy Administration Point – — Many distinct entities may act as PAPs – enterprise IT policy, department policy,

application-level policy

— Each entity independently manages its own policies but policies may be linked or depend upon other policies

• Policy Repository (PR)

— Aggregation and distribution point for policies

• Policy Enforcement Point

— There may be 100s or even 1000s of PEPs in an enterprise

— Embedded in devices or applications or infrastructure

— Performance constraints - some applications require may require 100s of authorization decision per second with low latency, others only a few decisions

Enterprise Requirements 2

• Policy Decision Point

— For performance and connectivity reasons, there may be multiple PDP instances

— Need for fail-over and horizontal scalability

— Some PDPs may need to function “in disconnected” mode

• Interaction between attribute sources, policy and pdp

— How does the context handler obtain needed additional attributes for Resources, Subject, Environment?

— How to distinguish between attributes originating from the PEP vs. additional attributes needed for policy evaluation?

— Under what conditions does the PDP and PEP participate in a multi-step interaction?

Understanding XACML Deployments

Policy Repository

P

A

P

PDP

PDP

PEP

PEP

PEP

PEP

PEP

Note: each componentmay be sourced from a different vendor

PDP

AttributeSources

Multiple PAPs and the Policy Repositorie (PR)

•Ability to bind administrator identity to policy

— Accomplished via trust model between PAP and PR

— Could take the form of TLS/SSL or use of digital signatures

— No real expansion of specifications required here

•Policy repository ensures that only policy originators can edit or delete existing policy

•Administrators should be able to browse and refer to existing policies in new policies

— Ability to reference existing policies available via <xacml:PolicyIdReference> element but processing rules undefined

— May need some profiling to be useful in an interoperable fashion

Policy Repository and PDP

•PDP provisioning presents significant challenges

— Download only relevant policy to PDP

•Bulk upload is also needed

— Some PDPs may operate in disconnected mode

•Network outage

•Disconnected device

— With large policy set, prefer to propagate only updates

•SAML 2.0 Profile of XACML 2.0

— <XacmlPolicyQuery>, <XacmlPolicyStatement> allows PDP to query Policy Repository and obtain policies

•Partial solution is available

— Should we look outside XACML for missing pieces?

PDP and PEP relationship

•The main challenge here is performance

— Some applications need to make 100s of authorization decisions with low latency requirement

•It may not be acceptable to make a network call for each authorization decision

•XML Marshalling and unmarshalling of <RequestContext> and <ResponseContext> may be too expensive

•Strategies to lower costs

— Define a language-specific binding for the authorization interface

•Should we pursue a JSR in this space?

— Other ways of minimizing costs include returning generalized results to the PEP and caching

Access to attributes

•Attributes originating from the PEP could be specified using new metadata specification

— Especially helpful when using vocabularies outside XACML

— Include information whether multi-step interactions are supported

— Types of obligations accepted

— Would aid in PDP PEP interoperability

•Standard interfaces for attribute access would also be helpful

— IGF includes an identity service for access to identity attributes

— What about resource and environment attributes?

Conclusion

•Promising technology – single framework for access policy across the enterprise

— Single format for policy specification

— Request/Response protocol for PEPs and applications

•Policy language is expressive and supports fine-grained authorization

— IGF and Fedora demonstrate creation of XACML vocabularies

•Enterprise deployments require solution of several problems

— Specification set may need to be extended

— Oracle products have already implemented some of these