XACML 2 0 in the Enterprise Use Cases

XACML 2. 0 in the Enterprise: Use. Cases 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? • • e. Xtensible 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 Policy. Set — A Policy is expressed through a set of Rules — a Policy. Set may contain multiple Policies or Policy. Sets, 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 Policy. Set, 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 (Request. Context) and determines whether or not to allow the Subject to execute the specified Action against the Resource • The Rule examines the Request. Context 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 Request. Context — Each Rule renders a decision based on the evaluation which can be one of: Permit, Deny, Indeterminate, Not. Applicable

XACML Request Response Model • Request. Context is normative structure for submitting a decision request — Request. Context contains Subject, Resource, Action, and Environment elements — A Policy is evaluated only in terms of its contents in relation to the Request. Context contents — Evaluation of the Policy results in an authorization decision: Permit, Deny, Indeterminate, or Not. Applicable • Response. Context is normative structure for returning an authorization decision — Response. Context contains Result element, which contains Decision element plus optional Resource. Id, Status, and Obligations elements

XACML Request. Context Example • The Request. Context contains the inputs that the PDP evaluates against the applicable Policy CN=Homer Simpson https: //med. example. com/Bart. Simpson. Record. jws read

XACML 2. 0 Specifications • XACML Core Specification: • XACML Resource Support: • XACML Subject Support: —“e. Xtensible Access Control Markup Language (XACML) Version 2. 0” —“Multiple resource profile of XACML v 2. 0” —“Hierarchical resource profile of XACML v 2. 0” —“Privacy policy profile of XACML v 2. 0” —“Core and hierarchical role based access control (RBAC) profile of XACML v 2. 0” • XACML Protocol Support: —“SAML 2. 0 Profile of XACML v 2. 0” (Auth. Z req/rsp, Policy distribution, and Attribute query protocols) —“XML Digital Signature profile of XACML v 2. 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, Variable. References • 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, Attribute. Designator, Attribute. Value Example (is the requested resource the Patient. Records web service? ): https: //med. example. com/Patient. Records. jws

XACML Attribute Expression Model 2 • Functional Expressions in Rules • • • Fine-grained authorization enabled with resource attributes Function, Subject/Resource. Attribute. Designators, Variable. Reference Example (Is Subject parent-guardian and (by Var. Ref) is patient under 16):

XACML Attribute Expression Model 3 • Variable Definitions - reusable • • Function, Environment/Resoure. Attribute. Selectors, Attribute. Value Example (is patient under 16 years old based on date today): P 16 Y

XACML Vocabularies and Obligations • XACML domain-specific vocabularies and constraints can be readily defined with existing XACML 2. 0 — http: //www. fedora. info/download/2. 2/userdocs/server/security/XACMLPolicy. Guide. 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 http: //www. example. com/marketing/* *

AAPML Example 2 • Resource constraints (specific data elements): Email. Address First. Name . . .

AAPML Example 3 • Action and Rule constraints: urn: aapml: 1. 0: names: action: read Marketing apps can access user information if explicit consent is available.

AAPML Example 4 • Obligations: http: //www. state. gov/userdata#Public. Gen. Law 2005

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 100 s or even 1000 s of PEPs in an enterprise Embedded in devices or applications or infrastructure Performance constraints - some applications require may require 100 s 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 P PEP Policy Repository PDP 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 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 , 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 100 s 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