XACML – The Standard Hal Lockhart, BEA Systems

What is XACML? n XML language for access control n Coarse or fine-grained n Extremely powerful evaluation logic n Ability to use any available information n Superset of Permissions, ACLs, RBAC, etc n Scales from PDA to Internet n Federated policy administration n OASIS and ITU-T Standard

Trends Driving Fine-Grained Access Control n De-perimeterization l No longer just “them and us” l Firewall is no longer sufficient n Service Oriented Architecture l Multiple access contexts for each service n Software as a Service (looking forward) l Complex interactions of internal and external components

OASIS XACML History n First Meeting – 21 May 2001 n Requirements from: Healthcare, DRM, Registry, Financial, Online Web, XML Docs, Fed Gov, Workflow, Java, Policy Analysis, WebDAV n XACML OASIS Standard – 6 February 2003 n XACML 1.1 – Committee Specification – 7 August 2003 n XACML 2.0 – OASIS Standard – 1 February 2005 n XACML 2.0 – ITU/T Recommendation X.1142

Powerful Policy Expression n “Anyone can use web servers with the ‘spare’ property between 12:00 AM and 4:00 AM” n “Salespeople can create orders, but if the total cost is greater that $1M, a supervisor must approve” n “Anyone view their own 401K information, but nobody else’s” n “The print formatting service can access printers and temporary storage on behalf of any user with the print attribute” n “The primary physician can have any of her patients’ medical records sent to a specialist in the same practice.”

Key XACML Features n Federated Policy Administration l Multiple policies applicable to same situation l Combining rules to resolve conflicts n Decision may include Obligations l In addition to Permit or Deny l Obligation can specify present or future action l Examples: Log request, require human approval, delete data after 30 days n Protect any resource l Web Server, Java or C++ Object, Room in building, Network Access, Web Service, Geographic Data, Health Records, etc.

Novel XACML Characteristics n Large Scale Environment l Subjects, Resources, Attributes, etc. not necessarily exist or be known at Policy Creation time l Multiple Administrators - potentially conflicting policy results l Combining algorithms n Request centric l Use any information available at access request time l Zero, one or more Subjects l No invented concepts (privilege, role, etc.) n Dynamically bound to request l Not limited to Resource binding l Only tell what policies apply in context of Request l Two stage evaluation

XACML Concepts n Request and Response Contexts – Input and Output n Policy & PolicySet – combining of applicable policies using CombiningAlgorithm n Target – Rapidly index to find applicable Policies or Rules n Conditions – Complex boolean expression with many operands, arithmetic & string functions n Effect – “Permit” or “Deny” n Obligations – Other required actions n Bag – unordered list which may contain duplicates

XACML Concepts PolicySet Policies Obligations Rules Target Obligations Condition Effect Target

Policies and Policy Sets n Policy l Smallest element PDP can evaluate l Contains: Description, Defaults, Target, Rules, Obligations, Rule Combining Algorithm n Policy Set l Allows Policies and Policy Sets to be combined l Use not required l Contains: Description, Defaults, Target, Policies, Policy Sets, Policy References, Policy Set References, Obligations, Policy Combining Algorithm n Combining Algorithms: Deny-overrides, Permit- overrides, First-applicable, Only-one-applicable

Request and Response Context

XACML 2.0 Profiles n Digital Signature l Integrity protection of Policies n Hierarchical Resources l Using XACML to protect files, directory entries, web pages n Privacy l Determine “purpose” of access n RBAC l Support ANSI RBAC Profile with XACML n SAML Integration l XACML-based decision request l Fetch applicable policies l Attribute alignment

XACML Benefits n Standard Policy Language l Investment protection l Skills reuse n Leverage XML tools n Policy not in application code l Reduce cost of changes l Consistent application l Enable audit

XACML Performance n Some public comments based on ignorance n Many optimization opportunities l Policy encoding l Request context l Partial evaluation l Decision Caching l Precomputed admin chaining n Complex policies cost more to evaluate than simple l But is the difference more significant that other factors?

Current Work - XACML 3.0 n Administration/Delegation n Schema generalization n WS-XACML n Obligation combining rules n Policy provisioning n Metadata/vocabulary advertisement n Closely coupled PDP/PEP

Delegation with XACML 2.0 n Use of Intermediary Subject Category l Print Format Service can read any file a user wants printed, but not otherwise l Access Subject + Intermediary Subject n Delegation by modifying attributes l User can enable family member’s access l Policy protects subject repository n Policies protecting each policy repository

Administration/Delegation n Two primary use cases l “HR-Admins can create policies concerning the Payroll servers” l “Jack can approve expenses while Mary is on vacation” n Backward compatible n Likely to define two compliance levels n Policies can contain Issuer n Policies can be Access or Admin n Admin policies enable policy creation

Administration/Delegation n Situation – all information values used as policy inputs n If policy issued by trusted issuer – use n If not, look for Admin policy for Issuer covering current Situation n Chain back to Trusted Issuer n Actual processing is complex, because of interplay with policy combining

Other 3.0 Work n Schema generalization l Improve extensibility n WS-XACML l Builds on WS-Security Policy – more fine grained l Good for privacy policies n Obligation combining rules l XACML 2.0 accumulates all Obligations l Characterize Obligation types – enable different treatments n Policy provisioning l From repository distribute distinct policy subsets