XACML 2.0 in the Enterprise: Use- Cases and Deployment Challenges Prateek Mishra, Frank Villavicencio, Rich Levinson Oracle Identity Management Group 02/07/ 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 CN=Homer Simpson read

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=" <AttributeValue DataType=" >

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): <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:example:attribute:parent-guardian-id" DataType=" <ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:example:attribute:parent-guardian-id" DataType="

XACML Attribute Expression Model 3 Variable Definitions - reusable Function, Environment/ResoureAttributeSelectors, AttributeValue Example (is patient under 16 years old based on date today): <EnvironmentAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-date" DataType=" <ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:example:attribute:patientDOB" DataType=" P16Y

XACML Vocabularies and Obligations XACML domain-specific vocabularies and constraints can be readily defined with existing XACML 2.0 — — — Identity Governance Framework (AAPML) — 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 — 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 <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-regexp-match"> <SubjectAttributeDesignator AttributeId="urn:aapml:1.0:names:subject:service-name" DataType=" <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-regexp-match"> <SubjectAttributeDesignator AttributeId="urn:aapml:1.0:names:subject:user-auth" DataType=" *

AAPML Example 2 Resource constraints (specific data elements): <ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <ResourceAttributeDesignator AttributeId="urn:aapml:1.0:names:resource:generic" DataType=" <AttributeValue DataType=" > Address <ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <ResourceAttributeDesignator AttributeId="urn:aapml:1.0:names:resource:generic" DataType=" <AttributeValue DataType=" >FirstName...

AAPML Example 3 Action and Rule constraints: <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType=" >urn:aapml:1.0:names:action:read <ActionAttributeDesignator AttributeId="urn:aapml:1.0:names:action" DataType=" <Rule RuleId="urn:aapml:1.0:names:rule-id:permit-if-consent-available" Effect="Permit"> Marketing apps can access user information if explicit consent is available.

AAPML Example 4 Obligations: <Obligation ObligationId="urn:aapml:1.0:names:obligation:consent" FulfillOn="Permit"> <AttributeAssignment AttributeId="urn:aapml:1.0:names:obligation:consent:agreement-identifier" DataType=" > <Obligation ObligationId="urn:aapml:1.0:names:obligation:do-not-cache" FulfillOn="Permit"/> <Obligation ObligationId="urn:aapml:1.0:names:obligation:do-not-propagate" FulfillOn="Permit"/>

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 PAPPAP PDP PEP Note: each component may be sourced from a different vendor PDPAttribute Sources

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 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 —, 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 and 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