OASIS Extensible Access Control Markup Language (XACML)
OASIS eXtensible Access Control Markup Language (XACML)
Working Draft 16, 16 22 August 2002
Document identifier: draft-xacml-specification-16.doc
Location: http://www.oasis-open.org/committees/xacml/docs/
Send comments to:
Editors:
Simon Godik, Overxeer ()
Tim Moses, Entrust ()
Contributors:
Anne Anderson, Sun Microsystems
Bill Parducci, Overxeer
Carlisle Adams, Entrust
Daniel Engovatov, Crosslogix
Don Flinn, Hitachi
Ernesto Damiani, University of Milan
James MacLean, Affinitex
Hal Lockhart, Entegrity
Ken Yagen, Crosslogix
Konstantin Besnozov, Hitachi
Michiharu Kudo, IBM, Japan
Pierangela Samarati, University of Milan
Polar Humenn, Syracuse University
Sekhar Vajjhala, Sun Microsystems
Gerald Brose, Xtradyne
Abstract:
This specification defines an XML schema for a commonan extensible access-control policy language.
Status:
This version of the specification is a working draft of the committee. As such, it is expected to change prior to adoption as an OASIS standard.
If you are on the list for committee members, send comments there. If you are not on that list, subscribe to the list and send comments there. To subscribe, send an email message to with the word "subscribe" as the body of the message.
Copyright (C) OASIS Open (date)2002. All Rights Reserved.
Table of contents
1. Glossary (non-normative) 11
1.1. Preferred terms 11
1.2. Related terms 12
2. Introduction (non-normative) 12
2.1. Background 12
2.2. Requirements 13
2.3. Rule and policy combining 14
2.4. Combining algorithms 14
2.5. Policies based on subject and resource attributes 15
2.6. Policies based on resource contents 15
2.7. Operators 15
2.8. Policy distribution 16
2.9. Policy indexing 16
2.10. Abstraction layer 16
2.11. Actions performed in conjunction with enforcement 17
2.12. Notation 17
2.13. Schema organization and namespaces 18
3. Examples (non-normative) 18
3.1. Example one 18
3.2. Example two 21
3.3. Example medical record instance 21
3.4. Example request context 22
3.5. Example plain-language rules 23
3.6. Example XACML rule instances 24
3.6.1 Rule 1 24
3.6.2 Rule 2 25
3.6.3 Rule 3 26
3.6.4 Rule 4 28
4. Models (non-normative) 30
4.1. Data-flow model 30
4.2. XACML context 33
4.3. Policy language model 33
4.3.1 Rule 35
4.3.2 Policy 36
4.3.3 Policy set 40
5. Policy syntax (normative, with the exception of the schema fragments) 41
5.1. Element <PolicySet> 41
5.2. Element <Description> 43
5.3. Element <PolicySetDefaults> 43
5.4. Element <Target> 43
5.5. Element <Subjects> 44
5.6. Element <Subject> 45
5.7. Element <SubjectMatch> 45
5.8. Element <Resources> 46
5.9. Element <Resource> 46
5.10. Element <ResourceMatch> 47
5.11. Element <Actions> 47
5.12. Element <Action> 48
5.13. Element <ActionMatch> 48
5.14. Element <PolicySetIdReference> 49
5.15. Element <PolicyIdReference> 49
5.16. Element <Policy> 49
5.17. Element <Rule> 50
5.18. Simple type EffectType 51
5.19. Element <Condition> 51
5.20. Element <Apply> 52
5.21. Complex type AttributeDesignatorType 53
5.22. Element <SubjectAttributeDesignator> 53
5.23. Element <ResourceAttributeDesignator> 54
5.24. Element <ActionAttributeDesignator> 54
5.25. Element <EnvironmentAttributeDesignator> 54
5.26. Element <SubjectAttributeDesignatorWhere> 54
5.27. Element <AttributeSelector> 55
5.28. Element <AttributeValue> 56
5.29. Element <Obligations> 56
5.30. Element <Obligation> 57
5.31. Element <AttributeAssignment> 57
6. Context syntax (normative with the exception of the schema fragments) 58
6.1. Element <Request> 58
6.2. Element <Subject> 59
6.3. Element <Resource> 59
6.4. Element <ResourceContent> 60
6.5. Element <Action> 60
6.6. Element <Environment> 60
6.7. Element <Attribute> 61
6.8. Element <AttributeValue> 61
6.9. Element <Response> 61
6.10. Element <Result> 62
6.11. Element <Decision> 62
6.12. Element <Status> 63
6.13. Element <StatusCode> 63
6.14. Element <StatusMessage> 64
6.15. Element <StatusDetail> 64
7. Operational model (normative) 69
8. XACML extensibility points (non-normative) 69
8.1. URIs 69
9. Security and privacy considerations (non-normative) 70
9.1. Authentication 70
9.2. Confidentiality 70
9.3. Communication Confidentiality 71
9.4. Statement Level Confidentiality 71
9.5. Policy Integrity 71
9.6. Policy Identifiers 72
9.7. Trust Model 72
9.8. Privacy 72
9.9. Operational Considerations 72
9.10. Resource Matching 73
9.11. Negative Policies 73
9.12. XACML Threat Model 74
9.12.1 Eavesdropping 74
9.12.2 Replay 74
9.12.3 Message Insertion 75
9.12.4 Message Deletion 75
9.12.5 Message Modification 75
9.12.6 Man-in-the-Middle 75
10. Conformance (normative) 78
10.1. Introduction 78
10.2. XACML test suite 78
Conformance tables 79
10.3.1 Schema elements 79
10.3.2 Algorithms 80
10.3.3 Identifiers 80
11. References 81
Appendix A. Function names and legal type combinations 83
A.1. Functions 83
Appendix B. XACML identifiers (normative) 93
B.1. XACML namespaces 93
B.2. Authentication locality 93
B.3. Access subject categories 93
B.4. XACML functions 94
B.5. Data types 94
B.5.1. X.500 distinguished name 94
B.5.2. RFC822 Name 94
B.5.3. Unix file-system path 94
B.5.4. Numeric 94
B.6. Environment attributes 95
B.7. Subject attributes 95
B.8. Resource attributes 96
B.9. Status codes 96
B.10. Combining algorithms 96
Identifiers used only in XACML conformance tests 97
B.11. Attributes used in examples 97
B.12. Actions used in examples 97
Appendix C. Combining algorithms (normative) 98
C.1. Deny-overrides 98
C.2. Permit-overrides 100
C.3. First-applicable 102
Appendix D. Acknowledgments 104
Appendix E. Revision history 105
Appendix F. Notices 106
1. Glossary (non-normative) 7
1.1. Preferred terms 7
1.2. Related terms 8
2. Introduction (non-normative) 8
2.1. Background 8
2.2. Requirements 9
2.3. Rule and policy combining 9
2.4. Combining algorithms 10
2.5. Policies based on subject and resource attributes 10
2.6. Policies based on resource contents 11
2.7. Operators 11
2.8. Policy distribution 12
2.9. Policy indexing 12
2.10. Abstraction layer 12
2.11. Actions performed in conjunction with enforcement 13
2.12. Notation 13
2.13. Schema Organization and Namespaces 14
3. Example (non-normative) 14
3.1. Example one 14
3.2. Example two 16
3.3. Example medical record instance 16
3.4. Example authorization decision request 18
3.5. Example plain-language rules 19
3.6. Example XACML rule instances 20
3.6.1 Rule 1 20
3.6.2 Rule 2 21
3.6.3 Rule 3 22
3.6.4 Rule 4 24
4. Models (non-normative) 25
4.1. Data-flow model 25
4.2. XACML Context 27
4.3. Policy language model 27
4.3.1 Rule 28
4.3.2 Policy statement 29
4.3.3 Policy set statement 33
5. Policy syntax (normative, with the exception of the schema fragments) 34
5.1. Element <PolicySet> 34
5.2. Element <Description> 36
5.3. Element <PolicySetDefaults> 36
5.4. Element <Target> 36
5.5. Element <Subjects> 37
5.6. Element <Subject> 37
5.7. Element <SubjectMatch> 38
5.8. Element <Resources> 38
5.9. Element <Resource> 39
5.10. Element <ResourceMatch> 39
5.11. Element <Actions> 40
5.12. Element <Action> 40
5.13. Element <ActionMatch> 40
5.14. Element <PolicySetIdReference> 41
5.15. Element <PolicyIdReference> 41
5.16. Element <Policy> 41
5.17. Element <Rule> 43
5.18. Simple Type EffectType 43
5.19. Element <Condition> 44
5.20. Element <Apply> 44
5.21. Complex type AttributeDesignatorType 45
5.22. Element <SubjectAttributeDesignator> 45
5.23. Element <ResourceAttributeDesignator> 46
5.24. Element <ActionAttributeDesignator> 46
5.25. Element <EnvironmentAttributeDesignator> 46
5.26. Element <SubjectAttributeDesignatorWhere> 47
5.27. Element <AttributeSelector> 47
5.28. Element <AttributeValue> 48
5.29. Element <Obligations> 48
5.30. Element <Obligation> 49
5.31. Element <AttributeAssignment> 49
6. Context Syntax (normative with the exception of the schema fragments) 50
6.1. Element <Request> 50
6.2. Element <Subject> 51
6.3. Element <Resource> 51
6.4. Element <ResourceContent> 52
6.5. Element <Action> 52
6.6. Element <Environment> 52
6.7. Element <Attribute> 53
6.8. Element <AttributeValue> 53
6.9. Element <Response> 53
6.10. Element <Result> 54
6.11. Element <Decision> 54
6.12. Element <Status> 55
6.13. Element <StatusCode> 55
6.14. Element <StatusMessage> 56
6.15. Element <StatusDetail> 56
7. Profiles (normative but not mandatory to implement) 56
7.1. SAML 56
7.1.1 XSLT transformation for generating XACML Request Context from SAML Request 56
7.1.2 XSLT transformation for generating SAML Response from XACML Response Context 58
7.2. XML Digital Signature 61
8. Operational Model (normative) 61
8.1. Policy Decision Point (PDP) 61
9. XACML extensibility points (non-normative) 61
9.1. URIs 61
10. Security and privacy (non-normative) 62
10.1. Authentication 62
10.2. Confidentiality 62
10.2.1 Communication Confidentiality 62
10.2.2 Statement Level Confidentiality 62
10.3. Policy Integrity 63
10.4. Elements included by reference 63
10.5. Trust Model 63
10.6. Privacy 64
11. Conformance (normative) 64
11.1. XACML schema elements, identifiers and algorithms 65
11.1.1 Schema Elements 65
11.1.2 Algorithms 66
11.1.3 Identifiers 66
12. References 67
Appendix A. Function names and legal type combinations 69
A.1. Functions 69
Appendix B. XACML identifiers (normative) 75
B.1. XACML identifiers 75
B.2. XACML Namespaces 75
B.3. Authentication Locality 75
B.4. Access Subject Categories 75
B.5. XACML functions 76
B.6. DataTypes 76
B.6.1. X.500 distinguished name 76
B.6.2. RFC822 Name 76
B.6.3. Unix file-system path 76
B.6.4. Numeric 76
B.7. Date Types 76
B.8. Environment attributes 77
B.9. Subject Attributes 77
B.10. Resource Attributes 77
B.11. Status Codes 78
B.12. Combining Algorithm 78
B.12.1. Deny-overrides rule-combining algorithm 78
B.12.2. Deny-overrides policy-combining algorithm 78
B.12.3. Permit-overrides rule-combining algorithm 78
B.12.4. Permit-overrides policy-combining algorithm 78
B.12.5. First-applicable rule-combining algorithm 79
B.12.6. First-applicable policy-combining algorithm 79
B.13. Identifiers Used Only In XACML Conformance Tests 79
B.14. Attributes Used In Examples 79
B.15. Actions Used in Examples 79
Appendix C. Combining algorithms (normative) 80
C.1. Deny-overrides 80
C.2. Permit-overrides 82
C.3. First Applicable Rule Combining Algorithm 84
Appendix D. Acknowledgments 86
Appendix E. Revision History 87
Appendix F. Notices 88
1. Glossary (non-normative)
1.1. Preferred terms
Access - Performing an action
Access control - Controlling access in accordance with a policy
Action - An operation on a resource
Applicable policy - The complete set of rulespolicy that governs access for a specific decision request
Attribute - Characteristic of a subject, resource, action or environment that may be referenced in a predicate
Authorization decision - The result of evaluating an applicable policy. A function that evaluates to "permit, deny or indeterminate", and (optionally) a set of obligations
Condition - An expression of predicates. A function that evaluates to "Ttrue" or "Ffalse"
Context - The canonical representation of decision request and authorization decision
Decision request - The request by a PEP to a PDP to render an authorization decision
Effect - The intended consequence of a satisfied condition (either "Ppermit" or "Ddeny")
Environment - The set of attributes that are independent of a particular subject, resource or action
Information request - The request by a PDP to a PIP for attributes
Obligation - An action operation specified in a policy or policy set that should be performed in conjunction with the issuance of an authorization decision
Policy - A set of rules, and an identifier for the rule-combining algorithm and obligations
Policy administration point (PAP) - The system entity that creates a policy or policy set
Policy-combining algorithm - The procedure for combining the target, obligations and rules conditions from multiple policies
Policy decision point (PDP) - The system entity that evaluates applicable policy and renders an authorization decision
Policy enforcement point (PEP) - The system entity that performs access control, by enforcing authorization decisions
Policy information point (PIP) - The system entity that acts as a source of attribute values
Policy retrieval point (PRP) - The system entity that locates and retrieves applicable policy for a particular decision request
Policy set - A set of policies, and other policy sets, and a policy-combining algorithm and obligations
Predicate - A statement about attributes whose truth can be evaluated
Resource - Data, service or system component
Rule - A target, an effect and a set of conditions
Rule-combining algorithm - The procedure for combining the target, effect and conditions from multiple rules
Subject - An actor whose attributes may be referenced by a predicate
Target - The set of decision requests, identified by definitions for resource, subject and action, that a rule, policy or policy set is intended to evaluate
Target mapping - The process of confirming that a rule, policy or policy set is applicable to an authorization decision request
1.2. Related terms
In the field of access control and authorization there are several closely related terms in common use. For purposes of precision and clarity, certain of these terms are not used in this specification.
For instance, the term attribute is used in place of the terms: group and role.
In place of the terms: privilege, permission, authorization, entitlement and right, we use the term rule.
The term object is also in common use, but we use the term resource in this specification.
Requestors and initiators are covered by the term subject.
2. Introduction (non-normative)
2.1. Background
The "economics of scale" have driven computing platform vendors to develop products with very generalized functionality, so that they can be used in the widest possible range of situations. "Out of the box", these products have the maximum possible privilege for accessing data and executing software, so that they can be used in as many application environments as possible, including those with the most permissive security policies. In the more common case of a relatively restricted security policy, the platform's inherent privileges must be constrained, by configuration.
The security policy of a large enterprise has many elements and many points of enforcement. Elements of policy may be managed by the Information Systems department, by Human Resources, by the Legal department and by the Finance department. And the policy may be enforced by the extranet, mail, WAN and remote-access systems; platforms which inherently implement a permissive security policy. The current practice is to manage the configuration of each point of enforcement independently in order to implement the security policy as accurately as possible. Consequently, it is an expensive and unreliable proposition to modify the security policy. And, it is virtually impossible to obtain a consolidated view of the safeguards in effect throughout the enterprise to enforce the policy. At the same time, there is increasing pressure on corporate and government executives from consumers, shareholders and regulators to demonstrate "best practice" in the protection of the information assets of the enterprise and its customers.
For these reasons, there is a pressing need for a common language for expressing security policy. If implemented throughout an enterprise, a common policy language allows the enterprise to manage the enforcement of all the elements of its security policy in all the components of its information systems. Managing security policy may include some or all of the following steps: writing, reviewing, testing, approving, issuing, combining, analyzing, modifying, withdrawing, retrieving and enforcing policy.