XACML 2.0 in the Enterprise: UseCases and Deployment Challenges

1
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

2
Agenda

• What is XACML?
• XACML Policies
• XACML 2.0 Specification Set
• Sample Policies
• Vocabularies and Applications
• AAPML A XACML Profile
• Deployment Models
• Challenges
• Conclusions

3
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

4
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.)

5
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

6
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

7
XACML RequestContext Example

• The RequestContext contains the inputs that the
  PDP evaluates against the applicable Policy
• ltRequest xmlns"urnoasisnamestcxacml2.0conte
  xtschemaos" xmlnsxsi"http//www.w3.org/2001/X
  MLSchema-instance" gt
• ltSubjectgt
• ltAttribute AttributeId"urnoasisnamestcxac
  ml1.0subjectsubject-id" DataType"xsstring"
  Issuer"med.example.com"gt
• ltAttributeValuegtCNHomer Simpsonlt/AttributeV
  aluegt
• lt/Attributegt
• lt/Subjectgt
• ltResourcegt
• ltAttribute AttributeId"urnoasisnamestcxac
  ml1.0resourceresource-id" DataType"http//www.
  w3.org/2001/XMLSchemaanyURI"/gt
• ltAttributeValuegthttps//med.example.com/Bart
  SimpsonRecord.jwslt/AttributeValuegt
• lt/Attributegt
• lt/Resourcegt
• ltActiongt
• ltAttribute AttributeId"urnoasisnamestcxac
  ml1.0actionaction-id" DataType"xsstring"gt
• ltAttributeValuegtreadlt/AttributeValuegt
• lt/Attributegt
• lt/Actiongt
• ltEnvironment/gt
• lt/Requestgt

8
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

9
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

10
XACML Attribute Expression Model 1

• Entity Matching within Rules
• Match, AttributeDesignator, AttributeValue
• Example (is the requested resource the
  PatientRecords web service?)
• ltResourceMatch
• MatchId"urnoasisnamestcxacml1.0functio
  nanyURI-equal"gt
• ltResourceAttributeDesignator
• AttributeId"urnoasisnamestcxacml1.0r
  esourceresource-id"
• DataType"http//www.w3.org/2001/XMLSchema
  anyURI"/gt
• ltAttributeValue
• DataType"http//www.w3.org/2001/XMLSchema
  anyURI"
• gthttps//med.example.com/PatientRecords.jwslt/A
  ttributeValuegt
• lt/ResourceMatchgt

11
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)
• ltConditiongt
• ltApply FunctionId"urnoasisnamestcxacml1.0
  functionand"gt
• ltApply FunctionId"urnoasisnamestcxacml1.
  0functionstring-equal"gt
• ltApply FunctionId"urnoasisnamestcxacml
  1.0functionstring-one-and-only"gt
• ltSubjectAttributeDesignator
• AttributeId"urnoasisnamestcxacm
  l2.0exampleattributeparent-guardian-id"
• DataType"http//www.w3.org/2001/XML
  Schemastring"/gt
• lt/Applygt
• ltApply FunctionId"urnoasisnamestcxacml
  1.0functionstring-one-and-only"gt
• ltResourceAttributeDesignator
• AttributeId"urnoasisnamestcxacm
  l2.0exampleattributeparent-guardian-id"
• DataType"http//www.w3.org/2001/XML
  Schemastring"/gt
• lt/Applygt
• lt/Applygt

12
XACML Attribute Expression Model 3

• Variable Definitions - reusable
• Function, Environment/ResoureAttributeSelectors,
  AttributeValue
• Example (is patient under 16 years old based on
  date today)
• ltVariableDefinition VariableId"17590035"gt
• ltApply FunctionId"urnoasisnamestcxacml2.0
  functiondate-less-or-equal"gt
• ltApply FunctionId"urnoasisnamestcxacml1.
  0functiondate-one-and-only"gt
• ltEnvironmentAttributeDesignator
• AttributeId"urnoasisnamestcxacml1.
  0environmentcurrent-date"
• DataType"http//www.w3.org/2001/XMLSche
  madate"/gt
• lt/Applygt
• ltApply FunctionId"urnoasisnamestcxacml1.
  0functiondate-add-yearMonthDuration"gt
• ltApply FunctionId"urnoasisnamestcxacml
  1.0functiondate-one-and-only"gt
• ltResourceAttributeDesignator
• AttributeId"urnoasisnamestcxacm
  l2.0exampleattributepatientDOB"
• DataType"http//www.w3.org/2001/XML
  Schemastring"/gt
• lt/Applygt
• ltAttributeValue DataType"http//www.w3.org/
  TR/2002/WD-xquery-operators-20020816yearMonthDura
  tion"gt
• ltxfdt-yearMonthDurationgtP16Ylt/xfdt-yearM
  onthDurationgt

13
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/serv
  er/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

14
XACML Vocabulary Example

• AAPML Attribute Authority Policy Markup Language
• http//www.oracle.com/technology/tech/standards/id
  m/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 urnaapml1.0names
• AAPML attributes used to constrain Subjects,
  Resources, Actions, identify Rules, and to
  specify Obligations that PEP must apply to
  requests

15
AAPML Example 1

• Subject constraints known accessing service,
  user with authentication attribute
• ltSubjectgt
• lt!-- This Subject pertains to the application
  making the request --gt
• lt!-- for a user. The application is known by
  its service-name, the --gt
• lt!-- identifier for which must match a regular
  expression prefix. --gt
• ltSubjectMatch
• MatchId"urnoasisnamestcxacml1.0functi
  onanyURI-regexp-match"gt
• ltSubjectAttributeDesignator
• AttributeId"urnaapml1.0namessubjects
  ervice-name"
• DataType"http//www.w3.org/2001/XMLSchema
  string"/gt
• ltAttributeValue DataType"http//www.w3.org/20
  01/XMLSchemastring"gt
• http//www.example.com/marketing/
• lt/AttributeValuegt
• lt/SubjectMatchgt
• lt!-- This subject pertains to the user that is
  making the request --gt
• lt!-- to the application. The user must have
  authenticated and have --gt
• lt!-- a non-null subjectuser-auth attribute
  --gt
• ltSubjectMatch
• MatchId"urnoasisnamestcxacml1.0functi
  onanyURI-regexp-match"gt

16
AAPML Example 2

• Resource constraints (specific data elements)
• ltResourcesgt
• lt!-- EmailAddress --gt
• ltResourcegt
• ltResourceMatch
• MatchId"urnoasisnamestcxacml1.0func
  tionstring-equal"gt
• ltResourceAttributeDesignator
• AttributeId"urnaapml1.0namesresourc
  egeneric"
• DataType"http//www.w3.org/2001/XMLSche
  mastring"/gt
• ltAttributeValue
• DataType"http//www.w3.org/2001/XMLSche
  mastring"
• gtEmailAddresslt/AttributeValuegt
• lt/ResourceMatchgt
• lt/Resourcegt
• lt!-- FirstName --gt
• ltResourcegt
• ltResourceMatch
• MatchId"urnoasisnamestcxacml1.0func
  tionstring-equal"gt
• ltResourceAttributeDesignator

17
AAPML Example 3

• Action and Rule constraints
• ltActionsgt
• ltActiongt
• ltActionMatch
• MatchId"urnoasisnamestcxacml1.0fu
  nctionstring-equal"gt
• ltAttributeValue
• DataType"http//www.w3.org/2001/XMLSc
  hemastring"
• gturnaapml1.0namesactionreadlt/Attribu
  teValuegt
• ltActionAttributeDesignator
• AttributeId"urnaapml1.0namesactio
  n"
• DataType"http//www.w3.org/2001/XMLSc
  hemastring"/gt
• lt/ActionMatchgt
• lt/Actiongt
• lt/Actionsgt
• lt/Targetgt
• ltRule
• RuleId"urnaapml1.0namesrule-idpermit-if-
  consent-available"
• Effect"Permit"gt

18
AAPML Example 4

• Obligations
• ltObligationsgt
• lt!-- This is an example obligation that refers
  to a legal restriction --gt
• lt!-- document, referencible at the state
  government site, which the --gt
• lt!-- PEP must notify the requestor is condition
  for use of the --gt
• lt!-- returned data.
  --gt
• ltObligation
• ObligationId"urnaapml1.0namesobligation
  consent"
• FulfillOn"Permit"gt
• ltAttributeAssignment
• AttributeId"urnaapml1.0namesobligatio
  nconsentagreement-identifier"
• DataType"http//www.w3.org/2001/XMLSchema
  anyURI"
• gthttp//www.state.gov/userdataPublicGenLaw20
  05lt/AttributeAssignmentgt
• lt/Obligationgt
• lt!-- This obligation says that any data
  returned from this request --gt
• lt!-- must not be cached, which the PDP must
  notify the requestor --gt
• ltObligation
• ObligationId"urnaapml1.0namesobligation
  do-not-cache"
• FulfillOn"Permit"/gt

19
Agenda
XACML Enterprise Deployment
20
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)

21
Actor Relationships
Extended PDP
22
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

23
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?

24
Understanding XACML Deployments
P AP
Note each componentmay be sourced from a
different vendor
25
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 ltxacmlPolicyIdReferencegt element but
  processing rules undefined
• May need some profiling to be useful in an
  interoperable fashion

26
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
• ltXacmlPolicyQuerygt, ltXacmlPolicyStatementgt allows
  PDP to query Policy Repository and obtain
  policies
• Partial solution is available
• Should we look outside XACML for missing pieces?

27
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
  ltRequestContextgt and ltResponseContextgt 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

28
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?

29
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

30
(No Transcript)
31
(No Transcript)