XACML 2.0 in the Enterprise: UseCases and Deployment Challenges
Prateek Mishra, Frank Villavicencio, Rich Levinson
Oracle 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:
•
XACML Resource Support:
•
XACML Subject Support:
—“eXtensible Access Control Markup Language (XACML) Version 2.0”
—“Multiple resource profile of XACML v2.0”
—“Hierarchical resource profile of XACML v2.0”
—“Privacy policy profile of XACML v2.0”
—“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/IGFAAPML-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
PEP
PDP
P
A
PEP
Policy
Repository
PDP
PEP
P
PEP
Attribute
Sources
PDP
Note: each component
may be sourced from a different vendor
PEP
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
—
•
SAML 2.0 Profile of XACML 2.0
—
•
With large policy set, prefer to propagate only updates
<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