d9db56472fd41226d193 …… · Web viewMichiharu Kudo, IBM, Japan. Pierangela Samarati, University...

OASIS eXtensible Access Control Markup Language (XACML)

Working Draft 16, 16 22 August 2002Document identifier: draft-xacml-specification-16.doc

Location: http://www.oasis-open.org/committees/xacml/docs/

Send comments to: [email protected]

Editors:Simon Godik, Overxeer ([email protected])Tim Moses, Entrust ([email protected])

Contributors:Anne Anderson, Sun MicrosystemsBill Parducci, OverxeerCarlisle Adams, EntrustDaniel Engovatov, CrosslogixDon Flinn, HitachiErnesto Damiani, University of MilanJames MacLean, AffinitexHal Lockhart, EntegrityKen Yagen, CrosslogixKonstantin Besnozov, HitachiMichiharu Kudo, IBM, JapanPierangela Samarati, University of MilanPolar Humenn, Syracuse UniversitySekhar Vajjhala, Sun MicrosystemsGerald 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 [email protected] list for committee members, send comments there. If you are not on that list, subscribe to the [email protected] list and send comments there. To subscribe, send an email message to [email protected] with the word "subscribe" as the body of the message.

draft-xacml-specification-16.doc

1

2

3

4

5

6

7

89101112131415161718192021222324252627

2829

30

3132

33343536

1

mailto:[email protected]?body=subscribe

mailto:[email protected]?body=subscribe

mailto:[email protected]

mailto:[email protected]

Copyright (C) OASIS Open (date)2002. All Rights Reserved.

draft-xacml-specification-16.doc 2

3738

2

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


39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

3

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.4. Element <ResourceContent> 60



76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

4

6.6. Element <Environment> 60

6.7. Element <Attribute> 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


113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

5

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


150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

6

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.7. Element <SubjectMatch> 38

5.8. Element <Resources> 38


187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

7


5.10. Element <ResourceMatch> 39

5.11. Element <Actions> 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.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.4. Element <ResourceContent> 52


6.6. Element <Environment> 52

6.7. Element <Attribute> 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


224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

8

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


261

262

263

264

265266

267268

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

288

289

290

291

292

293

294

295

296

297

298

9

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


299

300

301

302

303

304

305

306

307

308

309

310

311

312

313

314

315

316

317

318

319

320

321

322

323

324

10

1. Glossary (non-normative)

1.1. Preferred termsAccess - 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


325

326

327

328

329

330

331332

333334

335336

337

338

339

340

341342

343

344345

346

347

348349

350351

352353

354

11

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 termsIn 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. BackgroundThe "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


355356

357358

359

360

361

362363

364

365366

367368

369

370371

372

373374

375

376

377

378

379380381382383384

385386387388389

12

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.

XML is a natural choice as the basis for the common security-policy language, due to the ease with which its syntax and semantics can be extended to accommodate the unique requirements of this application, and the widespread support that it enjoys from all the main platform and tool vendors.

2.2. RequirementsThe basic requirements of a policy language for expressing information system security policy are:

To provide a method for combining individual rulesrules and ppoliciesy elements into a single policy statement set that applies to a given action.

To provide a method for flexible definition of the algorithm by which rules and policiesy elements are combined.

To provide a method for basing an authorization policy decision on attributes of the subject and resource.

To provide a method for basing an authorization policy decision on the contents of an information resource.

To provide a set of logical and mathematical operators on attributes of the subject, resource and environment.

To provide a method for distribution of policiesy statements by means of an enterprise repository, or their attachment to the resources to which they apply.

To provide a method for rapidly identifying the policy statement that applies to a given action, based either on the identity or attributes of either the subject or the resource.

To provide an abstraction-layer that insulates the policy-writer from the details of the application environment.

To provide a method for specifying a set of actions that must be performed in conjunction with policy enforcement.

The motivation behind XACML is to express these well-established ideas in the field of access-control policy using an extension language of XML. The XACML solutions for each of these requirements are discussed in the following sections.


390391392393394395

396397398399400401

402403404

405

406

407408

409410

411412

413414

415416

417418

419420

421422

423424

425426427

13

2.3. Rule and policy combiningThe complete policy applicable to a particular decision request may be composed of a number of individual rules or policyies statements, specified by different policy writers. For instance, in a personal privacy application, the owner of the personal information may define certain aspects of disclosure policy, whereas the enterprise that holds the information may define certain other aspects. In order to render an authorization decision, the PDP must be ableit must be possible to combine the two separate policiesy statements to form the single policy applicable to the request.

XACML defines three top-level policy elements: <Rule>, <Policy> and <PolicySet>. The <Rule> element contains a boolean expression that can be evaluated in isolation, but that is not intended to be passed between the major actors in the XACML architectural model. So, it is not intended to form the basis of an authorization decision by itself. It is intended to exist in isolation only within an XACML PAP, where it may form the basic unit of management, and be re-used in multiple policies.

The <Policy> element contains a set of <Rule> elements and a specified procedure for combining the results of their evaluation. It is the basic unit of policy that may be exchanged between the major actors in the XACML architectural model, and so it is intended to form the basis of an authorization decision.

The <PolicySet> element is a set of <Policy> or other <PolicySet> elements and a specified procedure for combining the results of their evaluation. It is the standard means for combining separate policies into a single combined policy.

Hinton et al [Hinton94] discuss the question of the compatibility of separate policies applicable to the same decision request.

2.4. Combining algorithmsXACML defines a number of combining algorithms that can be identified by a RuleCombiningAlgId or PolicyCombiningAlgId attribute of the <Policy> or <PolicySet> elements, respectively. The rule-combining algorithm defines a procedure for arriving at an authorization decision given the individual results of evaluation of a set of rules. Similarly, the policy-combining algorithm defines a procedure for arriving at an authorization decision given the individual results of evaluation of a set of policies. Standard combining algorithms are defined for:

Deny-overrides, and

Permit-overrides and.

First applicable.

In the first case, if a single <Rule> or <Policy> element is encountered that evaluates to "Ddeny", then, regardless of the evaluation result of the other <Rule> or <Policy> elements, the combined result is "DDeny". Likewise, in the second case, if a single "PPermit" result is encountered, then the combined result is "Permit". In the case of the "First applicable" combining algorithm, the combined result is the same as the result of evaluating the first rule in the list of rules whose target is applicable to the decision request.

Users of the standard may, if necessary, define their own combining algorithms. However, this approach is harmful to interoperability. Definitions for combining algorithms should specify how the combined result is to be derived from separate evaluation of the individual <Rule> or <Policy> elements.


428

429430431432433434

435436437438439440

441442443444

445446447

448449

450

451452453454455456457

458

459

460

461462463464465466

467468469470

14

2.5. Policies based on subject and resource attributesAnother common requirement is to base an authorization decision on some characteristic of the subject other than its identity. Perhaps, the most common application of this idea is the subject's role [RBAC]. XACML provides facilities to support this approach. Attributes of subjects are identified by the <SubjectAttributeDesignator> element. This element may contain a URN that identifies the attribute, or an XPath expression over the request context to identify a particular subject attribute value by its location in the context (see section 2.10 for an explanation of context). XACML provides a standard way to reference the attributes defined in the LDAP series of specifications [LDAP]. This is intended to encourage implementers to use standard attribute identifiers for some common subject attributes.

2.6. Policies based on resource contentsIn many applications, it is required to base an access authorization decision on data contained in the information resource to which access is requested. For instance, a common element of privacy policy is that a person should be allowed to read records for which he or she is the subject. The corresponding policy statement must contain a reference to the subject identified in the information resource itself.

XACML provides facilities for doing this when the information resource can be represented as an XML document. The <AttributeSelector> element may contain an XPath expression over the request context to identify data in the information resource to be used in the policy evaluation.

In cases where the information resource is not an XML document, specified attributes of the resource can be referenced.

2.7. OperatorsInformation security policies operate upon attributes of subjects and resources and the action to be performed on the resource in order to arrive at an authorization decision. In the process of arriving at the authorization decision, attributes of many different types may have to be compared or computed. For instance, in a financial application, a person's available credit may have to be calculated by adding their credit limit to their account balance. The result may then have to be compared with the transaction value. This sort of situation gives rise to the need for arithmetic operations on attributes of the subject (account balance and credit limit) and the resource (transaction value).

Even more commonly, a policy may identify the set of roles that are permitted to perform a particular action. The corresponding operation involves checking whether there is an non-empty intersection between the set of roles occupied by the subject and the set of roles identified in the policy. Hence the need for set operations.

XACML includes a number of built-in functions and a method of adding non-standard functions. These functions may be applied recursively to build arbitrarily complex expressions. This is achieved with the <Apply> element. The <Apply> element has an XML attribute called FunctionId that identifies the function to be applied to the contents of the element. Each standard function is defined for specific argument type combinations, and its return value is also specified. Therefore, type consistency of the policy can be checked at the time the policy is written. And, the types of the data values presented in the request context can be checked against the values expected by the policy to ensure a predictable outcome.

In addition to operators on numerical and set arguments, operators are defined for date, time and duration arguments. Date operations are notoriously difficult to standardize, due to local rules for


471

472473474475476477478479480

481

482483484485486

487488489

490491

492

493494495496497498499500

501502503504

505506507508509510511512

513514

15

handling weekends, statutory holidays, etc.. Therefore, the first level of XACML conformance does not require support for date operations.

Relationship operators (equality and inequality) are also defined for a number of data-types, including the RFC822 and X.500 name-forms, strings, URIs, etc..

Also noteworthy are the operators over boolean data types, which permit the logical combination of predicates in a rule. For example, a rule may contain the statement that access may be permitted during business hours AND from a terminal on business premises.

The XACML method of representing functions borrows heavily from MathML [MathML].

2.8. Policy distributionIn a distributed system, individual policy statements may be written by several policy writers and enforced at several enforcement points. In addition to facilitating the collection and combination of independent policy statements, this approach allows policies to be updated as required. XACML policy statements may be distributed in any one of a number of ways. But, XACML does not describe any normative way to do this. Regardless of the means of distribution, PDPs are expected to confirm, by examining the policy's <Target> element, that the policy is applicable to the decision request that it is processing.

Policy statements may be attached to the information resources to which they apply, as described by Perritt [Perritt93]. Alternatively, policies may be maintained in a central location from which they are retrieved for evaluation. In such cases, the applicable policy may be referenced by an identifier or locator closely associated with the information resource.

2.9. Policy indexingFor efficiency of evaluation and ease of management, the overall security policy in force across an enterprise may be expressed as multiple independent policy statements. In this case, it is necessary to identify and retrieve the applicable policy statement and verify that it is the correct one for the requested action before evaluating it. This is the purpose of the <Target> element in XACML.

Two approaches are supported:

1. Policy statements may be stored in a database, whose data-model is congruent with that of the <Target> element. The PDP should use the contents of the decision request that it is processing to form the database read command by which the required applicable policy statement is retrieved. However, the PDP should evaluate the <Target> element of the policy statement returned as a result of the read command as defined by the XACML specification.

2. Alternatively, the PDP may evaluate the <Target> element from each of the policies that it has available to it, in the context of a particular decision request, in order to identify the single policy that is applicable to that request.

In either case, it is the policy writer's responsibility to ensure that only one policy statement applies to a particular decision request.

The use of constraints limiting the applicability of a policy were described by Sloman [Sloman94].

2.10. Abstraction layerPEPs come in many forms. For instance, a PEP may be part of a remote-access gateway, part of a Web server or part of an email user-agent, etc.. It is unrealistic to expect that all PEPs in an


515516

517518

519520521

522

523

524525526527528529530

531532533534

535

536537538539540

541

542543544545546

547548549

550551

552

553

554555

16

enterprise do currently, or will in the future, issue decision requests to a PDP in a common format. Nevertheless, a particular element of policy may have to be enforced by multiple PEPs. It would be inefficient to force a policy writer to write the same policy several different ways in order to accommodate the format requirements of each PEP. Therefore, there is a need for a canonical form of the request and response handled by an XACML PDP. This canonical form is called the XACML "Context". Its syntax is defined in XML schema.

Naturally, XACML-conformant PEPs may issue requests and receive responses in the form of an XACML cContext. But, where this situation does not exist, an intermediate step is required to convert between the request/response format understood by the PEP and the XACML cContext format understood by the PDP.

The benefit of this approach is that policies may be written and analyzed independent of the specific environment in which they are to be enforced.

In the case where the native request/response format is specified in XML Schema (e.g. a SAML-conformant PEP), the transformation between the native format and the XACML cContext may be specified in the form of an Extensible Stylesheet Language Transformation [XSLT].

Similarly, in the case where the resource to which access is requested is an XML document, the resource itself may be included in, or referenced by, the request context. Then, through the use of XPath expressions [XPath] in the policy, values in the resource may be included in the policy evaluation.

2.11. Actions performed in conjunction with enforcementIn many applications, policies specify actions that MUST be performed, either instead of, or in addition to, actions that MAY be performed. This idea was described by Sloman [Sloman94]. XACML provides facilities to specify actions that MUST be performed in conjunction with policy evaluation in the <Obligations> element. There are no standard definitions for these actions in version 1.0 of XACML. Therefore, bilateral agreement between a policy writerPAP and the PEP that will enforce its policies is required for correct interpretation. PEPs that conform with v1.0 of XACML are required to deny access unless they understand all the <Obligations> elements associated with the applicable policy. <Obligations> elements are returned to the PEP for enforcement.

2.12. NotationThis specification contains schema conforming to W3C XML Schema and normative text to describe the syntax and semantics of XML-encoded policy statements.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in IETF RFC 2119 rfc2119:

"they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)"

These keywords are thus capitalized when used to unambiguously specify requirements over protocol and application features and behavior that affect the interoperability and security of implementations. When these words are not capitalized, they are meant in their natural-language sense.

Listings of XACML schemas appear like this.

Example code listings appear like this.


556557558559560561

562563564565

566567

568569570

571572573574

575

576577578579580581582583584

585

586587

588589590

591592

593594595596

597

598599

17

Conventional XML namespace prefixes are used throughout the listings in this specification to stand for their respective namespaces as follows, whether or not a namespace declaration is present in the example:

The prefix saml: stands for the SAML assertion namespace.

The prefix ds: stands for the W3C XML Signature namespace.

The prefix xs: stands for the W3C XML Schema namespace.

This specification uses the following typographical conventions in text: <XACMLElement>, <ns:ForeignElement>, Attribute, Datatype, OtherCode. Terms in italic bold-face are intended to have the meaning defined in the Glossary.

2.13. Schema oOrganization and nNamespacesThe XACML policy syntax is defined in a schema associated with the following XML namespace:

urn:oasis:names:tc:xacml:0.15i1.0:policy

The XACML context syntax is defined in a schema associated with the following XML namespace:

urn:oasis:names:tc:xacml:0.15i1.0:context

XACML functions have the following namespace prefix.

urn:oasis:names:tc:xacml:0.15i1.0:function

Note: The XACML namespace names are temporary and may change when XACML 1.0 is finalized.

The SAML assertion schema is imported into the XACML schema. Also imported is the schema for XML Signature XMLSigXSD, is imported into the XACML schema which and is associated with the following XML namespace:

http://www.w3.org/2000/09/xmldsig#

3. Examples (non-normative)This section contains an two examples of the use of XACML for illustrative purposes. The first example is a relatively simple one to illustrate the function of the XACML <Target> element, context, matching functions and subject attributes. The second example illustrates rule-combining and obligations.

3.1. Example one Assume that a corporation named Medi Corp (medico.com) has an access control policy that states, in English:

Any user with an e-mail name in the "medico.com" namespace is allowed to perform any action on any resource.

In XACML, this policy is expressed as follows:

<?xml version=1.0" encoding="UTF-8"?>


600601602

603

604

605

606607608

609

610

611

612

613

614

615

616617

618619620

621

622

623624625626

627

628629

630631

632

633

18

<Policy xmlns="urn:oasis:names:tc:xacml:1.0:context" xmlns:function="urn:oasis:names:tc:xacml:1.0:function" xmlns:identifier="urn:oasis:names:tc:xacml:1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:tc:xacml:1.0:policy http://www.oasis-open.org/tc/xacml/1.0/cs-xacml-schema-policy-01.xsd" PolicyId="identifier:example:SimplePolicy1" RuleCombiningAlgId="identifier:rule-combining-algorithm:deny-overrides"> <Description> Medi Corp access control policy </Description> <Target> <Subjects> <AnySubject/> </Subjects> <Resources> <AnyResource/> </Resources> <Actions> <AnyAction/> </Actions> </Target> <Rule RuleId="identifier:example:SimpleRule1" Effect="Permit"> <Description> Any subject with an e-mail name in the medico.com domain can perform any action on any resource. </Description> <Target> <Subjects> <Subject> <SubjectMatch MatchId="function:rfc822name-equalmatch"> <SubjectAttributeDesignator AttributeId="identifier:subject:subject-id" DataType="identifier:datatype:rfc822name"/> <AttributeValue DataType="identifier:datatype:rfc822name"> *@medico.com </AttributeValue> </SubjectMatch> </Subject> </Subjects> <Resources> <AnyResource/> </Resources> <Actions> <AnyAction/> </Actions> </Target> </Rule></xacml:Policy>

If Bart Simpson, with e-mail name "[email protected]", attempts to read his medical record at Medi Corp, his the request context looks as follows in XACML:

<?xml version="1.0" encoding="UTF-8"?><Request xmlns="urn:oasis:names:tc:xacml:1.0:context" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"


634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688

689690

691692693694

19

xsi:schemaLocation="urn:oasis:names:tc:xacml:1.0:context http://www.oasis-open.org/tc/xacml/1.0/sc-xacml-schema-context-01.xsd"> <Subject> <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType="identifier:rfc822name"> <AttributeValue> [email protected] </AttributeValue> </Attribute> </Subject> <Resource> <Attribute AttributeId="identifier:resource:resource-uri" DataType="xs:anyURI"> <AttributeValue> http://medico.com/record/patient/BartSimpson </AttributeValue> </Attribute> </Resource> <Action> <Attribute AttributeId="identifier:example:action" DataType="xs:string"> <AttributeValue> read </AttributeValue> </Attribute> </Action></Request>

The XACML Policy Decision Point (PDP) receiving processing this Request request context locates the pPolicy in its policy repository. It compares the sSubject, rResource, and aAction in the rRequest context against the sSubjects, rResources, and aActions in the policy tTarget. Since the policy tTarget matches the <AnySubject/>, <AnyResource/>, and <AnyAction/> elements, the policy applies to this Requestcontext.

The PDP now compares the sSubject, rResource, and aAction in the rRequest context against the tTarget of the one rRule in this policy. The requested resource matches <"AnyResource/>" element and the requested action matches the <"AnyAction/> element", but the requesting subject-id attribute does not match "*@medico.com".

As a result, there is no rRule in this pPolicy that returns a "Permit" result for this request. The rRule- Combining aAlgorithm for the pPolicy specifies that, in this case, a result of "Deny" should be returned. In XACML, theis response context looks as follows:

<?xml version="1.0" encoding="UTF-8"?><Response xmlns="urn:oasis:names:tc:xacml:1.0:context" xsi:schemaLocation="urn:oasis:names:tc:xacml:1.0:context http://www.oasis-open.org/tc/xacml/1.0/sc-xacml-schema-context-01.xsd"> <Result> <Decision> Deny </Decision> </Result></Response>


695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725

726727728729730

731732733734

735736737

738739740741742743744745746747748749

20

3.2. Example twoThis section contains an example XML document, an example request context and example XACML rules. The XML document is a medical record. Four separate rules are defined. These illustrate rule-combining and obligations.

3.3. Example medical record instanceFollowing is an instance of a medical record to which the example XACML rules can be applied. The <record> schema is defined in the registered namespace administered by "//medico.com".

<?xml version="1.0" encoding="UTF-8"?><record xmlns="medico.com/records.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="medico.com/records.xsd http://www.medico.com/schema/record.xsd"><patient>

<patientName><first>Bartholomew</first><last>Simpson</last>

</patientName><patientContact>

<street>27 Shelbyville Road</street><city>Springfield</city><state>MA</state><zip>12345</zip><phone>555.123.4567</phone><fax/><email/>

</patientContact><patientDoB xsi:type="date">1992-03-21</patientDoB><patientGender xsi:type="string">male</patientGender><policyNumber xsi:type="string">555555</policyNumber>

</patient><parentGuardian>

<parentGuardianName><first>Homer</first><last>Simpson</last>

</parentGuardianName><parentGuardianContact>

<street>27 Shelbyville Road</street><city>Springfield</city><state>MA</state><zip>12345</zip><phone>555.123.4567</phone><fax/><email>[email protected]</email>

</parentGuardianContact></parentGuardian><primaryCarePhysician>

<physicianName><first>Julius</first><last>Hibbert</last>

</physicianName><physicianContact>

<street>1 First St</street><city>Springfield</city><state>MA</state><zip>12345</zip><phone>555.123.9012</phone><fax>555.123.9013</fax>


750

751752753

754

755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806

21

<email/></physicianContact><registrationID>ABC123</registrationID>

</primaryCarePhysician><insurer>

<name>Blue Cross</name><street>1234 Main St</street><city>Springfield</city><state>MA</state><zip>12345</zip><phone>555.123.5678</phone><fax>555.123.5679</fax><email/>

</insurer><medical>

<treatment><drug>

<name>methylphenidate hydrochloride</name><dailyDosage>30mgs</dailyDosage><startDate>1999-01-12</startDate>

</drug><comment>patient exhibits side-effects of skin coloration and

carpal degeneration</comment></treatment><result>

<test>blood pressure</test><value>120/80</value><date>2001-06-09</date><performedBy>Nurse Betty</performedBy>

</result></medical>

</record>

3.4. Example authorization decision request contextThe following example illustrates a request context to which the example rules are intended to be applicable. It represents a request by the physician Julius Hibbert to read the patient date of birth in the record of Bartholomew Simpson. It includes an a SAML authentication assertion and an attribute assertion containing the role of the requestor.

<?xml version="1.0" encoding="UTF-8"?><Request xmlns="urn:oasis:names:tc:xacml:0.16f:context" xmlns:identifier="urn:oasis:names:tc:xacml:identifier" xmlns:xacml="urn:oasis:names:tc:xacml:0.16f:policy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:tc:xacml:0.16f:context draft-xacml-schema-context-16f.xsd"><Subject>

<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-category" Issuer="www.medco.com"

IssueInstant="2001-12-17T09:30:47-05:00">

<AttributeValue>urn:oasis:names:tc:xacml:1.0:subjectcategory:access-subject</AttributeValue>

</Attribute><Attribute

AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" Issuer="www.medco.com"

IssueInstant="2001-12-17T09:30:47-05:00">


807808809810811812813814815816817818819820821822823824825826827828829830831832833834835836837838

839

840841842843

844845846847848849850851852853854855

856857858860861862863864

22

<AttributeValue>Julius Hibbert</AttributeValue></Attribute><Attribute

AttributeId="urn:oasis:names:tc:xacml:1.0:subject:name-format" Issuer="www.medco.com"

IssueInstant="2001-12-17T09:30:47-05:00">

<AttributeValue>urn:oasis:names:tc:xacml:1.0:datatype:x500name</AttributeValue>


AttributeId="urn:oasis:names:tc:xacml:1.0:example:attribute:role" Issuer="www.medco.com"

IssueInstant="2001-12-17T09:30:47-05:00"><AttributeValue>physician</AttributeValue>


AttributeId="urn:oasis:names:tc:xacml:1.0:example:attribute:physician-id" Issuer="www.medco.com"

IssueInstant="2001-12-17T09:30:47-05:00"><AttributeValue>jh1234</AttributeValue>

</Attribute></Subject><Resource>

<ResourceContent><md:record xmlns:md="http:www.medco.com/shemas/record.xsd">

<md:patient><md:patientDoB>1992-03-21</md:patientDoB>

</md:patient>

</md:record></ResourceContent><Attribute

AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-uri"><AttributeValue>

//medco.com/records/bart-simpson.xml#

xmlns(md=http:www.medico.com/schemas/record.xsd)xpointer(/md:record/md:patient/md:patientDoB)

</AttributeValue></Attribute><Attribute

AttributeId="urn:oasis:names:tc:xacml:1.0:resource:xpath"><AttributeValue>

xmlns(md=http:www.medico.com/schemas/record.xsd)xpointer(/md:record/md:patient/md:patientDoB)

</AttributeValue></Attribute>

</Resource><Action>

<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action"><AttributeValue>read</AttributeValue>

</Attribute></Action>

</Request>


865866867868869870

871872873875876877878879880881882883884885886887888889890891892893894895896897898899900901

902903904906907908909910

911912913915916917918919920921922923

23

3.5. Example plain-language rulesThe following plain-language rules are to be enforced:

1. A person may read any record for which he or she is the designated patient.

2. A person may read any record for which he or she is the designated parent or guardian, and for which the patient is under 16 years of age.

3. A physician may write any medical element for which he or she is the designated primary care physician, provided an email is sent to the patient,

4. An administrator shall not be permitted to read or write medical elements of a patient record.

These rules may be written by different PAPs, operating independently, or by a single PAP.

3.6. Example XACML rule instances

3.6.1 Rule 1Rule 1 illustrates a simple rule with a single <Ccondition> element.. The following XACML <Rule> instance expresses Rule 1.

<?xml version="1.0" encoding="UTF-8"?><Rule xmlns="urn:oasis:names:tc:xacml:0.16f:policy" xmlns:function="urn:oasis:names:tc:xacml:0.16f:function" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:tc:xacml:0.16f:policy draft-xacml-schema-policy-16f.xsd" xmlns:ctx="urn:oasis:names:tc:xacml:0.16f:context" xmlns:md="http:www.medco.com/schemas/record.xsd" RuleId="urn:oasis:names:tc:xacml:examples:ruleid:1" Effect="Permit"><Description>

A person may read any record defined by the http://www.medco.com/scheams/record.xsd namespace

for which he or she is a designated patient</Description><Target>

<Subjects><AnySubject/>

</Subjects><Resources>

<Resource><ResourceMatch MatchId="function:string-match">

<ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:resource:target-namespace"

DataType="xsi:string"/><AttributeValue

DataType="xsi:string">http://www.medco.com/schemas/record.xsd</AttributeValue>

</ResourceMatch><ResourceMatch MatchId="function:node-match">

<ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:resource:xpath"


DataType="xsi:string">/md:record</AttributeValue></ResourceMatch>

</Resource></Resources>


924

925

926

927928

929930

931

932

933

934

935936937938939940941942943944945946947948949950951952953954955956957958959960961962963964965966967968969970971972973

24

<Actions><Action>

<ActionMatch MatchId="function:string-equal"><ActionAttributeDesignator

AttributeId="urn:oasis:names:tc:xacml:action" DataType="xsi:string"/>

<AttributeValue DataType="xsi:string">read</AttributeValue>

</ActionMatch></Action>

</Actions></Target><Condition FunctionId="function:string-equal">

<SubjectAttributeDesignatorWhere

AttributeId="urn:oasis:names:tc:xacml:examples:attribute:policy-number" DataType="xsi:string"/>

<AttributeSelector RequestContextPath=

"/ctx:Request/ctx:Resource/ctx:ResourceContent/md:record/md:patient/md:policyNumber"

DataType="xsi:string"/></Condition>

</Rule>

3.6.2 Rule 2Rule 2 illustrates the use of a mathematical function, i.e. the <MinusApply> element with functionId value of function:date-subtract function to calculate age. It also illustrates the use of predicate expressions, with the functionId value of function:and<And> and <Not> elements.

<?xml version="1.0" encoding="UTF-8"?><Rule xmlns="urn:oasis:names:tc:xacml:0.16f:policy" xmlns:function="urn:oasis:names:tc:xacml:0.16f:function" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:tc:xacml:0.16f:policydraft-xacml-schema-policy-16f.xsd" xmlns:ctx="urn:oasis:names:tc:xacml:0.16f:context" xmlns:md="http:www.medco.com/schemas/record.xsd" RuleId="urn:oasis:names:tc:xacml:examples:ruleid:2" Effect="Permit"><Description>

A person may read any medical record defined by the http://www.medco.com/records.xsd namespace

for which he or she is the designated patient or guardian, and for which the patient is under 16 years of age</Description><Target>







</ResourceMatch>


974975976977978979980981982983984985986987

988989991

992993994996997998

999

10001001100210031004100510061007100810091010101110121013101410151016101710181019102010211022102310241025102610271028102910301031

25

<ResourceMatch MatchId="function:node-match"><ResourceAttributeDesignator

AttributeId="urn:oasis:names:tc:xacml:resource:xpath" DataType="xsi:string"/>

<AttributeValue DataType="xsi:string">/md:record</AttributeValue>

</ResourceMatch></Resource>

</Resources><Actions>

<Action><ActionMatch MatchId="function:string-equal">

<ActionAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:action" DataType="xsi:string"/>



</Actions></Target><Condition FunctionId="function:and">

<Apply FunctionId="function:string-equal"><SubjectAttributeDesignatorWhere

AttributeId="urn:oasis:names:tc:xacml:examples:attribute:parent-guardian-id"

DataType="xs:string"/><AttributeSelector RequestContextPath=

"/ctx:Request//ctx:ResourceContent/md:record/md:parentGuardian/md:parentGuardianId"

DataType="xs:string"/></Apply><Apply FunctionId="function:dayTimeDuration-greater-than">

<Apply FunctionId="function:date-substract"><EnvironmentAttributeDesignator

AttributeId="urn:oasis:names:tc:xacml:env:date"DataType="xs:date"/>


"/ctx:Request//ctx:ResourceContent/md:patient/md:patientDoB"DataType="xs:date"/>

</Apply><AttributeValue

DataType="xs:dateTimeDuration">16-0-0</AttributeValue></Apply>

</Condition></Rule>

3.6.3 Rule 3Rule 3 illustrates the use of an obligation. The XACML <Rule> element syntax does not include an element suitable for carrying an obligation, therefore Rule 3 has to be formatted as a <PolicyStatement> element, which is a type of SAML assertion.

<?xml version="1.0" encoding="UTF-8"?>


1032103310341035103610371038103910401041104210431044104510461047104810491050105110521053105410551056105710581059

10601061106210641065106610671068106910701071

10721074107510761077107810791080

1081

1082108310841085

26

<Policy xmlns="urn:oasis:names:tc:xacml:0.16f:policy" xmlns:function="urn:oasis:names:tc:xacml:0.16f:function" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:tc:xacml:0.16f:policy draft-xacml-schema-policy-16f.xsd" xmlns:ctx="urn:oasis:names:tc:xacml:0.16f:context" xmlns:md="http:www.medco.com/schemas/record.xsd" PolicyId="urn:oasis:names:tc:xacml:examples:policyid:3" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides"><Description>

Policy for any medical record defined by the http://www.medco.com/schemas/record.xsd namespace</Description><Target>







</ResourceMatch></Resource>

</Resources><Actions>

<AnyAction/></Actions>

</Target><Rule RuleId="urn:oasis:names:tc:xacml:examples:ruleid:3"

Effect="Permit"><Description>

A physician may write any medical element is a record for which he or she is the designated primary

care physician, provided an email is sent to the patient</Description><Target>

<Subjects><Subject>

<SubjectMatch MatchId="function:string-match"><SubjectAttributeDesignator

AttributeId="urn:oasis:names:tc:xacml:1.0:examples:attribute:group"DataType="xsi:string"/>

<AttributeValue DataType="xs:string">physician</AttributeValue>

</SubjectMatch></Subject>


<Resource><ResourceMatch MatchId="function:node-match">



DataType="xsi:string">/md:record/md:medical</AttributeValue></ResourceMatch>


10861087108810891090109110921093109410951096109710981099110011011102110311041105110611071108110911101111111211131114111511161117111811191120112111221123112411251126112711281129113011311132113311341135113611371138113911401141114211431144114511461147

27

</Resource></Resources><Actions>



<AttributeValue DataType="xsi:string">write</AttributeValue>


</Actions></Target><Condition FunctionId="function:string-equal">

<SubjectAttributeDesignatorWhere

AttributeId="urn:oasis:names:tc:xacml:examples:attribute:physician-id" DataType="xsi:string"/>


"/ctx:Request/ctx:Resource/ctx:ResourceContent/md:record/md:primaryCarePhysician/md:physicianId"

DataType="xsi:string"/></Condition>

</Rule><Obligations>

<Obligation ObligationId="urn:oasis:names:tc:xacml:examples:obligation:email" FulfilOn="Permit">

<AttributeAssignment AttributeId="urn:oasis:names:tc:xacml:examples:attribute:mailto" DataType="xs:string">


"/ctx:Request//ctx:ResourceContent/md:/record/md:patient/md:patientContact/md:email"

DataType="xs:string"/></AttributeAssignment><AttributeAssignment

AttributeId="urn:oasis:names:tc:xacml:examples:attribute:text" DataType="xs:string">

<AttributeValue DataType="xs:string">Your medical record has been accessed by:</AttributeValue>

</AttributeAssignment><AttributeAssignment

AttributeId="urn:oasis:names:tc:xacml:examples:attribute:text" DataType="xs:string">

<SubjectAttributeDesignator AttributeId="urn:osasis:names:tc:xacml:subject:subject-id" DataType="xs:string"/>

</AttributeAssignment></Obligation>

</Obligations></Policy>


1148114911501151115211531154115511561157115811591160116111621163

116411651167

11681169117011721173117411751176117711781179118011811182

118311841185118711881189119011911192119311941195119611971198119912001201120212031204

28

3.6.4 Rule 4Rule 4 illustrates the use of the "Deny" effect value, and a <Rrule> with no <Condition> element.

<?xml version="1.0" encoding="UTF-8"?><Rule xmlns="urn:oasis:names:tc:xacml:0.16f:policy" xmlns:function="urn:oasis:names:tc:xacml:0.16f:function" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:tc:xacml:0.16f:policydraft-xacml-schema-policy-16f.xsd" xmlns:ctx="urn:oasis:names:tc:xacml:0.16f:context" xmlns:md="http:www.medco.com/schemas/record.xsd" RuleId="urn:oasis:names:tc:xacml:example:ruleid:4" Effect="Deny"><Description>

An Administrator shall not be permitted to read or write medical elements of a patient record defined by

the http://www.medico.com/records.xsd namespace.</Description><Target>

<Subjects><Subject>

<SubjectMatch MatchId="function:string-equal"><SubjectAttributeDesignator

AttributeId="urn:oasis:names:tc:xacml:1.0:example:attribute:role"DataType="xs:string"/>

<AttributeValue DataType="xs:string">administrator</AttributeValue>

</SubjectMatch></Subject>






</ResourceMatch><ResourceMatch MatchId="function:node-match">



DataType="xsi:string">/md:record/md:medical</AttributeValue></ResourceMatch>

</Resource></Resources><Actions>




</ActionMatch></Action><Action>

<ActionMatch MatchId="function:string-equal">


1205

12061207

120812091210121112121213121412151216121712181219122012211222122312241225122612271228122912301231123212331234123512361237123812391240124112421243124412451246124712481249125012511252125312541255125612571258125912601261126212631264

29


<AttributeValue DataType="xsi:string">write</AttributeValue>


</Actions></Target>

</Rule>

4. Models (non-normative)The context domain model and schema language model of XACML are described in two models. These models are: the data-flow model and the policy language model. They are described in the following sub-sections.

4.1. Data-flow modelThe major actors in the XACML domain are shown in the data-flow diagram of Figure 1.


1265126612671268126912701271127212731274

1275

127612771278

1279

1280

30

PEP

contexthandler

8. requestcontext

PIP

4. attributequery

9. responsecontext

1. policy

6. attribute

environment

resource

subjects

5b. envrionmentattributes

PAP

obligationsservice

11. obligations

PDP

accessrequester

2. access request

7. resource

3. request10. response

5c. resourceattributes

5a. subjectattributes


1281

31

PEP

contexthandler

8. requestcontext

PIP

4. attributequery

9. responsecontext

1. policy

6. attribute

environment

resource

subjects

5b. envrionmentattributes

PAP

obligationsservice

11. obligations

PDP

accessrequester

2. access request

7. resource

3. request10. response

5c. resourceattributes

5a. subjectattributes

Figure 1 - Data-flow diagram

Note: some of the data-flows shown in the diagram may be facilitated by a repository. For instance, the communications between the PDP context handler and the PIP or the communications between the PDP and the PRP PIP or the communication between the PAP and the PRP may be facilitated by a repository. The XACML specification is not intended to place restrictions on the location of any such repository, or indeed to prescribe a particular communication protocol for any of the data-flows.

The model operates by the following steps.

1. PAPs write policies and make them available to the PDP. Its policies represent the complete policy for a particular target.

2. The access requester sends a request for access to the PEP.

3. The PEP sends the request for access to the context handler in its native request format. The context handler constructs a request context in accordance with steps 4,5,6 and 7.

4. Subject, resource and environment attributes are requested from a PIP.

5. The PIP obtains the requested attributes.

6. The PIP returns the requested attributes to the context handler.

7. Optionally, the context handler includes the resource in the context.


1282

1283

128412851286128712881289

1290

12911292

1293

12941295

1296

1297

1298

1299

32

8. The context handler sends the request context to the PDP. The PDP identifies the policy applicable to the request context. The PDP evaluates the policy.

9. The PDP returns the response context to the context handler.

10. The context handler translates the response context to the native response format of the PEP. The context handler returns the response to the PEP.

11. The PEP fulfills the obligations.

12. If access is permitted, then PEP permits access to the resource.

The request context and response contexts are the environment-agnostic inputs/outputs for an XACML-conformant PDP. For any specific environment (e.g., SAML, J2SE, CORBA) conversion processes will be needed to transform from the environment-specific inputs to the xacmlContext:request, and from the xacmlContext:response to the environment-specific outputs.

4.2. XACML cContextXACML is designed to be applicable to a variety of application environments. The core language is insulated from the application environment by the XACML context, as shown in Figure 2, in which the scope of XACML is indicated by the shaded area. The XACML context is an defined in XML schema describing a canonical representation for the inputs and outputs of the PDP. Attributes referenced by an instance of XACML SHALL may be in the form of XPath expressions on the context. Implementations must convert between the attribute representations in the application environment (e.g., SAML, J2SE, CORBA, and so on) and the attribute representations in the XACML context. How this is achieved is outside the scope of the XACML specification. In some cases, such as SAML, this conversion may be accomplished in an automated way through the use of an XSLT transformation.

domain-specificinputs

domain-specificoutputs

xacmlContext/request.xml

xacmlContext/response.xmlPDP

xacml.xml

Figure 2 - XACML cContext

4.3. Policy language modelThe policy language model is shown in Figure 3. The main components of the model are:

Rule;

Policy statement; and

Policy set statement.

These are described in the following sub-sections.


13001301

1302

13031304

1305

1306

1307130813091310

1311

1312131313141315131613171318131913201321

1322

1323

1324

1325

1326

1327

1328

1329

33

1

1..*

1

1..*

1

1..*

Condition

Target

Rule

1 0..1

Policy

1

1

Obligations

1

1

1

0..*

1

-<no name>

0..1

ActionResourceSubject

PolicySet

1

0..*

1

1

PolicyCombiningAlogorithm

1

0..*

RuleCombiningAlgorithm

1

0..*

1

0..1

10..1


1330

34

1

1..*

1

1..*

1

1..*

Condition

Target

Rule

1 0..1

Policy

1

1

Obligations11

1

1

1

0..*

1 1

ActionResourceSubject

PolicySet

1

0..*

1

1

PolicyCombiningAlgorithm

1

0..*

RuleCombiningAlgorithm

1

0..*

1

0..1

Figure 3 - Policy language model

4.3.1 RuleThe main components of a rule are:

a target;

an effect; and

a condition.

These are discussed in the following sub-sections.

4.3.1.1 Rule tTarget

The target defines the set of:

resources;


1331

1332

1333

1334

1335

1336

1337

1338

1339

1340

1341

35

subjects; and

actions

to which the rule is intended to apply. If the rule is intended to apply to all entities of a particular type, then the target definition is the root of the applicable name spacean empty element named <AnySubject/>, <AnyResource/> or <AnyAction/> is used. An XACML PDP verifies that the resources, subjects and actions identified in the request context are each included in the target of the rules that it uses to evaluate the decision request. Target definitions are discrete, in order that they may be indexed by the PDP.

4.3.1.2 Effect

The effect of the rule indicates the rule-writer's intended consequence of a true evaluation for the rule. Two values are allowed: "Ppermit" and "Ddeny".

4.3.1.3 Condition

Condition is a general expression of predicates of attributes. It should not duplicate the exact predicates implied by the target. Therefore, it may be nullempty.

4.3.1.4 Rule evaluation

A rule has a value that can be calculated by evaluating its contents. Rule evaluation involves separate evaluation of the rule's target and condition. The rule truth table is shown in Table 1.

Target Condition Rule

Match True Effect

Match False Not applicable

Match Indeterminate Indeterminate

No-match True Not applicable

No-match False Not applicable

No-match Indeterminate Not applicable

Table 1 - Rule truth table

The target value is "Match" if the resource, subject and action specified in the request context are each in the target defined in the rule. Otherwise, its value is "No-match".

The condition value is True if the <Condition> element is nullempty, or if it evaluates "True" for the attribute values supplied in, or referenced by, the request context. Its value is "False" if the <Condition> element evaluates False for the attribute values supplied in, or referenced by, the request context. If any attribute value referenced in the condition cannot be obtained, then the condition evaluates Indeterminate.

4.3.2 Policy statementFrom the data-flow model one can see that rules are not exchanged amongst system entities. Therefore, a PAP combines rules in a policy. A policy comprises four main components:

a target;


1342

1343

134413451346134713481349

1350

13511352

1353

13541355

1356

13571358

1359

13601361

13621363136413651366

1367

13681369

1370

36

a rule-combining algorithm-identifier;

a set of rules; and

obligations.

Rules are described above. The remaining components are described in the following sub-sections.

4.3.2.1 Policy tTarget

The target of a policy must include all the decision requests that it the policy is intended to evaluate. The target may be declared by the writer of the policy, or computed from the targets of its component rules.

If the target of the policy statement is computed from the targets of the component rules, two approaches are permitted:

the target of the policy may be the union of the target definitions for resource, subject and action that are contained in the component rules; or

the target of the policy may be the intersection of the target definitions for resource, subject and action that are contained in the component rules.

In the former case, the target may be omitted from the individual rules, and the targets from the component rules must be included in the form of conditions in their respective rules. As an example, the following rule target and condition may be merged in a single condition.

Target<Target><Subjects MatchId="function:rfc822Name-equal"

DataType="xs:boolean"><AttributeDesignator

Designator="//xacmlContext/Request/Subject/Attribute[@DataType='identifier:rfc822Name']" DataType="identifier:rfc822Name"/>

<Attribute DataType="identifier:rfc822Name">@</Attribute></Subjects><Resources MatchId="function:string-match" DataType="xs:boolean">

<AttributeDesignator Designator="//xacmlContext/Request/Resource/@ResourceURI" DataType="xs:anyURI"/>

<Attribute DataType="xs:anyURI">//medico.com/record.*</Attribute></Resources><Actions MatchId="function:subset" DataType="xs:boolean">

<AttributeDesignator Designator="//xacmlContext/Action[@Namespace=]" DataType="xs:string"/>

<Attribute DataType="xs:string">read</Attribute></Actions>

</Target>

Condition<Condition FunctionId="function:string-equal" DataType="xs:boolean"><AttributeDesignator

Designator="//xacmlContext/Request/Subject/Attribute[@DataType='identifier:patientName']" DataType="xs:string"/><AttributeDesignator

Designator="//xacmlContext/Request/Resource/patientName" DataType="xs:string"/>


1371

1372

1373

13741375

1376

137713781379

13801381

13821383

13841385

138613871388

1389

1390139113921393139413951396139713981399140014011402140314041405140614071408140914101411

1412

1413141414151416141714181419

37

</Condition>

Following is the merged Condition condition.

<Condition FunctionId="function:and" DataType="xs:boolean"><Function FunctionId="function:string-match" DataType="xs:boolean">

<AttributeDesignator Designator="//xacmlContext/Request/Resource/@ResourceURI" DataType="xs:anyURI"/>

<Attribute DataType="xs:anyURI">//medico.com/record.*</Attribute></Function><Function FunctionId="function:subset" DataType="xs:boolean">


<Attribute DataType="xs:string">read</Attribute></Function><Function FunctionId="function:string-equal" DataType="xs:boolean">

<AttributeDesignator Designator="//xacmlContext/Request/Subject/Attribute[@DataType='identifier:patientName']" DataType="xs:string"/>

<AttributeDesignator Designator="//xacmlContext/Request/Resource/patientName" DataType="xs:string"/></Function>

</Condition>

In the case where the policy target is computed as the intersection of the targets of the individual rules, the targets may be omitted from the individual rules.

In the case that a rule target is present, the rule is evaluated according to the truth table of Table 1.

4.3.2.2 Rule-combining algorithm

The rule-combining algorithm specifies the algorithm procedure by which the results of evaluating the component rules are combined, when evaluating the policy.

The result of evaluating the policy is defined by the rule-combining algorithm. In the case that the PDP uses a policy to determine its response to a decision request, the saml:Decision value is the value of the policy, as defined by the rule-combining algorithm.

See Section B.11Appendix C for an example of a rule-combining algorithm.

4.3.2.3 Obligations

The XACML <Rule> syntax does not contain an element suitable for carrying obligations, therefore, if required in a policy, obligations must be added by the writer of the policy.

When a PDP evaluates a policy containing obligations, it returns certain of those obligations to the PEP in its response context. The obligations that it returns to the PEP are those whose xacml:FulfilOn attributes have the same value as the result of evaluating the policy.

4.3.2.4 Example policy statement

This section uses the example of Section 3 to illustrate the process of combining rules. The policy governing read access to medical elements of a record is formed from each of the four rules. In plain language, the combined rule is:


1420

1421

14221423142414251426142714281429143014311432143314341435143614371438143914401441144214431444

14451446

14471448

1449

14501451

145214531454

1455

1456

14571458

145914601461

1462

146314641465

38

Either the requestor is the patient; or

the requestor is the parent or guardian and the patient is under 16; or

the requestor is the primary care physician and a notification is sent to the patient; and

the requestor is not an administrator.

The following XACML <PolicyStatement> illustrates the combined rules. Rules 1 and 4 are included by reference, rule 2 is included as a digest, and rule 3 is explicitly included.

<?xml version="1.0" encoding="UTF-8"?><saml:Assertion MajorVersion="0" MinorVersion="28" AssertionID="A7F34K90" Issuer="medico.com" IssueInstant="2002-03-22T08:23:47-05:00"><PolicyStatement PolicyId="//medico.com/rules/policy5"

RuleCombiningAlgId="urn:oasis:names:tc:XACML:identifier:ruleCombiningAlgorithms:denyOverrides" xmlns="urn:oasis:names:tc:xacml:0.15i:policy" xmlns:function="urn:oasis:names:tc:xacml:0.15i:function" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:tc:xacml:0.15i:policyD:\MYDOCU~1\Standards\XACML\v15\draft-xacml-schema-policy-15i.xsd">

<Target><Subjects MatchId="function:superset" DataType="xs:boolean">

<AttributeDesignator Designator="//xacmlContext/Request/Subject/Attribute[@DataType='identifier:role']" DataType="xs:string"/>

<Attribute DataType="xs:string"></Attribute></Subjects><Resources MatchId="function:anyURI-equal"


Designator="//xacmlContext/Request/Resource/@ResourceURI" DataType="xs:anyURI"/>

<Attribute DataType="xs:anyURI">//medico.com/record/medical.*</Attribute>

</Resources><Actions MatchId="function:subset" DataType="xs:boolean">


<Attribute DataType="xs:string">read</Attribute></Actions>

</Target><RuleSet>

<RuleDesignator><RuleId>//medico.com/rules/rule1</RuleId>

</RuleDesignator><RuleDesignator>

<RuleDigest Base64Digest="H7jiE0+jwkn63k/JhB3+D9aI4V3J9z/o0"/>

</RuleDesignator><Rule RuleId="//medico.com/rules/rule3" Effect="Permit">

<Description>A physician may write any medical element for which he or she is the designated primary care physician</Description>

<Condition FunctionId="function:and" DataType="xs:boolean"><Function FunctionId="function:string-equal"

DataType="xs:boolean">


1466

1467

1468

1469

14701471

14721473147414751476147714781479148014811482148314841485148614871488148914901491149214931494149514961497149814991500150115021503150415051506150715081509151015111512151315141515151615171518151915201521

39

<AttributeDesignator Designator="//xacmlContext/Request/Subject/SubjectId" DataType="xs:string"/>

<AttributeDesignator Designator="//xacmlContext/Request/Resource/physicianName" DataType="xs:string"/>

</Function><Function FunctionId="function:present"


Designator="//xacmlContext/Request/Resource/patient/email" DataType="xs:string"/>

</Function></Condition>

</Rule><RuleDesignator>

<RuleId>//medico.com/rules/rule4</RuleId></RuleDesignator>

</RuleSet><Obligations>

<Obligation ObligationId="//medico.com/emailer" FulfilOn="Permit">

<AttributeDesignator Designator="//xacmlContext/Request/Resource/patient/email" DataType="xs:string"/>

<AttributeAssignment DataType="xs:string" AttributeId="//medico.com/text">Your medical record has been accessed by:</AttributeAssignment>

<AttributeDesignator Designator="//xacmlContext/Request/Subject/SubjectId" DataType="xs:string"/>

</Obligation></Obligations>

</PolicyStatement></saml:Assertion>

4.3.3 Policy set statementA policy set comprises four main components:

a target;

a set of policiesy statements;

obligations; and

a policy-combining algorithm-identifier.

The target and policy statement components are to be interpreted as described above. The other components are described in the following sub-sections.

4.3.3.1 Obligations

The writer of a policy set statement MAY may add obligations to the policy set, in addition to those contained in the component policies and policy sets.

4.3.3.2 Policy-combining algorithm

The policy-combining algorithm is the algorithm procedure by which the results of evaluating the component policies are combined to form the value of the policy set. In the case that the PDP


15221523152415251526152715281529153015311532153315341535153615371538153915401541154215431544154515461547154815491550155115521553155415551556

1557

1558

1559

1560

1561

1562

15631564

1565

15661567

1568

15691570

40

uses a policy set to determine its response to a decision request, the saml:Decision value is the result of evaluating the policy set.

When a PDP evaluates a policy set containing obligations, it returns certain of those obligations to the PEP in its response context. The XACML <Oobligation> elements that are returned to the PEP are those whose xacml:FulfilOn attributes have the same value as the result of evaluating the policy set.

As a consequence of this procedure, no obligations are returned to the PEP if the policies from which they are drawn are not evaluated or their evaluated result is Indeterminate or Not applicable.

See Section B.10.4Appendix C for an example of a policy-combining algorithm.

5. Policy syntax (normative, with the exception of the schema fragments)

5.1. Element <PolicySet>The <PolicySet> element is a top-level element in the XACML policy schema. <PolicySet> is an aggregation of other policy sets and policies. Policy sets MAY be included into an enclosing <PolicySet> element either directly by the <PolicySet> element or indirectly by the <PolicySetIdReference> element. Policies MAY be included into an enclosing <PolicySet> either directly by the <Policy> element or indirectly by the <PolicyIdReference> element.

If a<PolicySet> element contains references to other policy sets or policies in the form of URIs, then these references MAY be resolvable. Applications MAY use SAML protocol extensions to query for the <PolicySetAssertion> or <PolicyAssertion> by reference.

Policies included in the <PolicySet> element MUST be combined by the algorithm specified by the PolicyCombiningAlgId attribute.

The <Target> element defines the applicability of the <PolicySet> to authorization decision requests. If there is a match between the <Target> element within <PolicySet> and the authorization decision request, then the <PolicySet> element MAY be used by the PDP in making the authorization decision.

The <Obligations> element is a set of obligations that MUST be fulfilled by the PEP upon in conjunction with the authorization decision. If the PEP does not understand any obligation, then it MUST act as if the PDP returned a “Deny” authorization decision value.

<xs:element name="PolicySet" type="xacml:PolicySetType"/><xs:complexType name="PolicySetType">

<xs:sequence><xs:element ref="xacml:Description" minOccurs="0"/><xs:element ref="xacml:PolicySetDefaults" minOccurs="0"/><xs:element ref="xacml:Target"/><xs:choice minOccurs="0" maxOccurs="unbounded">

<xs:element ref="xacml:PolicySet"/><xs:element ref="xacml:Policy"/><xs:element ref="xacml:PolicySetIdReference"/><xs:element ref="xacml:PolicyIdReferece"/>

</xs:choice><xs:element ref="xacml:Obligations" minOccurs="0"/>


15711572

1573157415751576

15771578

1579

1580

1581

1582

158315841585158615871588

158915901591

15921593

1594159515961597

159815991600

1601160216031604160516061607160816091610161116121613

41

</xs:sequence><xs:attribute name="PolicySetId" type="xs:anyURI"

use="required"/><xs:attribute name="PolicyCombiningAlgId" type="xs:anyURI"

use="required"/></xs:complexType>

The <PolicySet> element is of PolicySetType complex type.

The <PolicySet> element contains the following attributes and elements:

PolicySetId [Required]

Policy set identifier. The Pparty assigning the identifier MUST minimize the potential of some other party reusing the same identifier. This MAY be achieved by following a predefined urn URN or uri URI scheme. If the policy set identifier is in the form of a URI it MAY be resolvable.

PolicyCombiningAlgId [Required]

The identifier of the pPolicy- combining algorithm identifier by which various the <PolicySet> components MUST be combined. Standard policy-combining algorithms are listed in Appendix C. Standard pPolicy- combining algorithm identifiers are listed in Section B.11.Table xx

<Description> [Optional]

A fFree- form description of the <PolicySet>.

<PolicySetDefaults> [Optional]

A set of default values applicable to the <PolicySet>. This set of policy defaults does not propagate down into <PolicySet> components.

<Target> [Required]

The <Target> element defines the applicability of a <PolicySet> to authorization decision requests.

The <Target> element MAY be declared by the creator of the <PolicySet> or it MAY be computed from the <Target> elements of the referenced <Policy> elements, either as an intersection or as a union.

If the <xacml-context:Subject>, <xacml-context:Resource>, and <xacml-context:Action> elements of the <xacml-context:Request> element match the <Subjects>, <Resources>, and <Actions> elements of the <Target> within the <PolicySet> element, then it MAY be used by the PDP in making an authorization decision.

<PolicySet> [Any Number]

A Ppolicy set component that is included in this policy set.

<Policy> [Any Number]

The pPolicy component that is included in this policy set.

<PolicySetIdReference> [Any Number]


161416151616161716181619

1620

1621

1622

1623162416251626

1627

1628162916301631

1632

1633

1634

16351636

1637

16381639

164016411642

16431644164516461647

1648

1649

1650

1651

1652

42

A rReference to the <PolicySet> component that MUST be included in this policy set. If <PolicySetIdReference> is an URI, then it MAY be resolvable. Applications MAY use SAML protocol extensions to query <PolicySet> by reference.

<PolicyIdReference> [Any Number]

A rReference to the <Policy> component that MUST be included in this policy set. If the <PolicyIdReference> is an URI, then it MAY be resolvable. Applications MAY use SAML protocol extensions to query <Policy> by reference.

<Obligations> [Optional]

Contains the set of <Obligation> elements that MUST be discharged by the PEP. If the PEP does not understand any obligation in this set, then it MUST act as if the authorization decision request was denied by the PDP.

5.2. Element <Description>The <Description> element is used for a free- form description of the <PolicySet> element and <Policy> element. The <Description> element is of xs:string simple type.

<xs:element name="Description" type="xs:string"/>

5.3. Element <PolicySetDefaults>The <PolicySetDefaults> element is used to specify default values for the <PolicySet> element.

<xs:element name="PolicySetDefaults" type="xacml:DefaultsType"/><xs:complexType name="DefaultsType">

<xs:sequence minOccurs="0" maxOccurs="unbounded"><xs:element ref="xacml:AbstractDefaults"/>

</xs:sequence></xs:complexType>

<PolicySetDefaults> element is of DefaultsType complex type.

<AbstractDefaults> [Any Number]

This is the head of a substitution group to specify default parameters. The only element in this substitution group defined at this time is the <XpathVersion> element.

5.4. Element <Target>The <Target> element identifies the set of decision requests that the parent element is intended to evaluate. The <Target> element appears as a child of <PolicySet>, <Policy>, and <Rule> elements. It contains definitions for subjects, resources, and actions.

<xs:element name="Target" type="xacml:TargetType"/><xs:complexType name="TargetType">

<xs:sequence><xs:element ref="xacml:Subjects"/><xs:element ref="xacml:Resources"/><xs:element ref="xacml:Actions"/>



165316541655

1656

165716581659

1660

166116621663

1664

166516661667

1668

16691670

167116721673167416751676

1677

1678

16791680

1681

16821683168416851686168716881689169016911692

43

If the subject, resource, and action in the <xacml-context:Request> element match the definitions of subjects, resources, and actions in the <Target> element, then the policy component containing the <Target> element MAY be applicable to the decision request.

For the purposes of matching, the <Subjects>, <Resources>, and <Actions> children of the <Target> element are combined with using the logical ‘AND’ operation. For the parent of the <Target> element to be applicable to the authorization decision request, at least one <Subject>, one <Resource>, and one <Action> MUST match the corresponding elements in the <xacml-context:Request> request contextelement.

The <Target> element is of TargetType complex type.

Note: a dDisjunctive sequence is a sequence of elements combined with using the logical ‘OR’ operation.

<Subjects> [Required]

This element is either a disjunctive sequence of <Subject> elements that match this target with subject attributes in the request context, or a special element <AnySubject> that matches any subject attribute in the request context.

<Resources> [Required]

This element is either a disjunctive sequence of <Resource> elements that match this target with resource attributes in the request context, or a special element <AnyResource> that matches any resource attribute in the request context.

<Actions> [Required]

This element is either a disjunctive sequence of <Action> elements that match this target with action attributes in the request context, or a special element <AnyAction> that matches any action attribute in the request context.

5.5. Element <Subjects>The <Subjects> element is a child of the <Target> element and is a wrapper for the disjunctive sequence of the <Subject> elements. The <Subjects> element is combined by using the logical ‘AND’ operation with other children of the <Target> element.

<xs:element name="Subjects" type="xacml:SubjectsType"/><xs:complexType name="SubjectsType"><xs:choice>

<xs:element ref="xacml:Subject" maxOccurs="unbounded"/><xs:element ref="xacml:AnySubject"/>

</xs:choice></xs:complexType>

The <Subjects> element is of SubjectsType complex type.

<Subject> [Required]

A disjunctive sequence of one or more matching specifications against subject attributes in the request context.

<AnySubject> [Required]

An element matching any subject attribute in the request context.


169316941695

16961697169816991700

1701

17021703

1704

170517061707

1708

170917101711

1712

171317141715

1716

1717171817191720172117221723172417251726

1727

1728

17291730

1731

1732

44

5.6. Element <Subject>Note: a cConjunctive sequence is a sequence of elements combined with using the logical ‘AND’ operation.

The <Subject> element is a conjunctive sequence of individual matches against subject attributes in the request context.

<xs:element name="Subject" type="xacml:SubjectType"/><xs:complexType name="SubjectType">

<xs:sequence><xs:element ref="xacml:SubjectMatch" maxOccurs="unbounded"/>


The <Subject> element is of SubjectType complex type.

<Subject> element contains following elements:

<SubjectMatch> [One to Many]

A cConjunctive sequence of individual matches with the subject attributes in the request context.

5.7. Element <SubjectMatch>The <SubjectMatch> element identifiesy a set of subject- related entities by matching values in the <Ssubject> portion element of the context with values embedded in the <Ppolicy> element.

<xs:element name="SubjectMatch" type="xacml:SubjectMatchType"/><xs:complexType name="SubjectMatchType">

<xs:sequence><xs:choice>

<xs:element ref="xacml:SubjectAttributeDesignator"/><xs:element ref="xacml:AttributeSelector"/>

</xs:choice><xs:element ref="xacml:AttributeValue"/>

</xs:sequence><xs:attribute name="MatchId" type="xs:QName" use="required"/>

</xs:complexType>

The <SubjectMatch> element is of SubjectMatchType complex type.

The <SubjectMatch> element contains following attributes and elements:

MatchId [required]

Specifies a matching function. The vValue of this attribute MUST be of type Qname, with legal values documented in Table xxxAppendix A.

<SubjectAttributeDesignator> [required]

Identifies one or more values in the <Ssubject> portion element of the <xacml-context:Request> element.

<AttributeSelector> [required]


1733

17341735

17361737

173817391740174117421743

1744

1745

1746

17471748

1749

175017511752

17531754175517561757175817591760176117621763

1764

1765

1766

17671768

1769

17701771

1772

45

MAY be used to identify one or more values in the <Ssubject> portion element of <xacml-context:Request> element. It MUST contain a legal xpath expression over the <Ssubject> portion element of the <xacml-context:Request> element.

5.8. Element <Resources>The <Resources> element is a child of the <Target> element and is a wrapper for the disjunctive sequence of the <Resource> elements. The <Resources> element is combined by using the logical ‘AND’ operation with other children of the <xacml:Target> element.

<xs:element name="Resources" type="xacml:ResourcesType"/><xs:complexType name="ResourcesType">

<xs:choice><xs:element ref="xacml:Resource" maxOccurs="unbounded"/><xs:element ref="xacml:AnyResource"/>


The <Resources> element is of ResourcesType complex type.

The <Resources> element consists of the following elements:

<Resource> [Required]

A disjunctive sequence of one or more matching specifications against resource attributes in the request context.

<AnyResource> [Required]

An element matching any resource attribute in the request context.

5.9. Element <Resource>The <Resource> element is a conjunctive sequence of individual matches against the resource attributes in the request context.

<xs:element name="Resource" type="xacml:ResourceType"/><xs:complexType name="ResourceType">

<xs:sequence><xs:element ref="xacml:ResourceMatch" maxOccurs="unbounded"/>


The <Resource> element is of ResourceType complex type.

The <Resource> element contains the following elements:

<ResourceMatch> [One to Many]

A cConjunctive sequence of individual matches with the resource attributes in the request context.

5.10. Element <ResourceMatch>The <ResourceMatch> element identifiesy a set of resource- related entities by matching values in the <Rresource> portion element of the request context with values embedded in the <Ppolicy> element.


177317741775

1776

1777177817791780178117821783178417851786

1787

1788

1789

17901791

1792

1793

1794

17951796

179717981799180018011802

1803

1804

1805

18061807

1808

180918101811

46

<xs:element name="ResourceMatch" type="xacml:ResourceMatchType"/><xs:complexType name="ResourceMatchType">

<xs:sequence><xs:choice>

<xs:element ref="xacml:ResourceAttributeDesignator"/><xs:element ref="xacml:AttributeSelector"/>



</xs:complexType>

The <ResourceMatch> element is of ResourceMatchType complex type.

The <ResourceMatch> element contains the following attributes and elements:

MatchId [Required]

Specifies a matching function. Value of this attribute MUST be of type Qname, with legal values documented in Table xxxAppendix A.

<ResourceAttributeDesignator> [Required]

Identifies one or more values in the <Rresource> portion element of the <xacml-context:Request> element.

<AttributeSelector> [Required]

MAY be used to identify one or more values in the <Rresource> portion element of the <xacml-context:Request> element. It MUST contain a legal xpath expression over the <Rresource> portion element of the <xacml-context:Request> element.

5.11. Element <Actions>The <Actions> element is a child of the <Target> element and is a wrapper for the disjunctive sequence of the <Action> elements. The <Actions> element is combined by logical ‘AND’ with other children of the <Target> element.

<xs:element name="Actions" type="xacml:ActionsType"/><xs:complexType name="ActionsType"><xs:choice>

<xs:element ref="xacml:Action" maxOccurs="unbounded"/><xs:element ref="xacml:AnyAction"/>


The <Actions> element is of ActionsType complex type.

The <Actions> element contains the following elements:

<Action> [Required]

A disjunctive sequence of one or more matching specifications against action attributes in the request context.

<AnyAction> [Required]

An element matching any action attribute in the request context.


18121813181418151816181718181819182018211822

1823

1824

1825

18261827

1828

18291830

1831

183218331834

1835

1836183718381839184018411842184318441845

1846

1847

1848

18491850

1851

1852

47

5.12. Element <Action>The <Action> element is a conjunctive sequence of individual matches against the action attributes in the request context.

<xs:element name="Action" type="xacml:ActionType"/><xs:complexType name="ActionType"><xs:sequence>

<xs:element ref="xacml:ActionMatch" maxOccurs="unbounded"/></xs:sequence>

</xs:complexType>

The <Action> element is of ActionType complex type.

The <Action> element contains the following elements:

<ActionMatch> [One to Many]

A cConjunctive sequence of individual action matches with the action in the request context.

5.13. Element <ActionMatch>The <ActionMatch> element identifiesy a set of action- related entities by matching values in the <Aaction> portion element of the context with values embedded in the <Ppolicy> element.

<xs:element name="ActionMatch" type="xacml:ActionMatchType"/><xs:complexType name="ActionMatchType"><xs:sequence>

<xs:choice><xs:element ref="xacml:ActionAttributeDesignator"/><xs:element ref="xacml:AttributeSelector"/>



</xs:complexType>

The <ActionMatch> element is of ActionMatchType complex type.

The <ActionMatch> element contains the following attributes and elements:

MatchId [Required]

Specifies a matching function. The vValue of this attribute MUST be of type Qname, with legal values documented in Table xxxAppendix A.

<ActionAttributeDesignator> [Required]

Identifies one or more values in the <Rresource> portion element of the <xacml-context:Request> element.

<AttributeSelector> [Required]

MAY be used to identify one or more values in the <Aaction> portion element of the <xacml-context:Request> element. It MUST contain a legal xpath expression over the <Rresource> portion element of <xacml-context:Request> element.


1853

18541855

185618571858185918601861

1862

1863

1864

18651866

1867

1868186918701871187218731874187518761877187818791880

1881

1882

1883

18841885

1886

18871888

1889

189018911892

48

5.14. Element <PolicySetIdReference>The <PolicySetIdReference> element is used to reference a <PolicySet> element by id. If <PolicySetIdReference> is a URI, then it MAY be resolvable to the <PolicySet>. The mMechanism for resolving a policy set reference to the corresponding policy set is implementation dependent. Applications MAY use the xacml SAML protocol extension to query <PolicySetStatement> by id.

<xs:element name="PolicySetIdReference" type="xs:anyURI"/>

Element <PolicySetIdReference> is of xs:anyURI simple type.

5.15. Element <PolicyIdReference>The <xacml:PolicyIdReference> element is used to reference a <Policy> element by id. If <PolicyIdReference> is a URI, then it MAY be resolvable to the <Policy>. The mMechanism for resolving a policy reference to the corresponding policy is implementation dependent. Applications MAY xacml use the xacml SAML protocol extension to query <PolicyStatement> by id.

<xs:element name="PolicyIdReference" type="xs:anyURI"/>

Element <PolicyIdReference> is of xs:anyURI simple type.

5.16. Element <Policy>The <Policy> element is the smallest entity that can be presented to the PDP for evaluation.

The main components of this element are the <Target>, <Rule>, and <Obligations> elements and the RuleCombiningAlgId attribute.

The <Target> element defines <Policy> applicability to authorization decision requests. A sequence of <Rule> elements specifiesy authorizations that MUST be combined according to the RuleCombiningAlgId attribute. The <Obligations> element contains a set of obligations that MUST be discharged by the PDP as a result ofin conjunction with the authorization decision.

<xs:element name="Policy" type="xacml:PolicyType"/><xs:complexType name="PolicyType">

<xs:sequence><xs:element ref="xacml:Description" minOccurs="0"/><xs:element ref="xacml:PolicyDefaults" minOccurs="0"/><xs:element ref="xacml:Target"/><xs:element ref="xacml:Rule" minOccurs="0"

maxOccurs="unbounded"/><xs:element ref="xacml:Obligations" minOccurs="0"/>

</xs:sequence><xs:attribute name="PolicyId" type="xs:anyURI" use="required"/><xs:attribute name="RuleCombiningAlgId" type="xs:anyURI"


The <Policy> element is of PolicyType complex type.

The <Policy> element contains the following attributes and elements:

PolicyId [Required]


1893

189418951896189718981899

1900

1901

19021903190419051906

1907

1908

1909

1910

19111912

1913191419151916

19171918191919201921192219231924192519261927192819291930

1931

1932

1933

49

Policy identifier. The pParty assigning identifier this identifier MUST minimize the potential of some other party reusing the same identifier. This MAY be achieved by following a predefined urn URN or uri URI scheme. It is OPTIONAL for the PolicyId URI to be resolvable to the corresponding <Policy> object.

RuleCombiningAlgId [Required]

Rule combining algorithm identifier contains a reference to the rule-combining algorithm by which <Rule> elements MUST be combined. <Policy> element MUST understand rule-combining algorithm. Currently defined rule combining algorithms are specified in table xxx. The identifier of the rule-combining algorithm by which the <Policy> components MUST be combined. Standard rule-combining algorithms are listed in Appendix C. Standard rule-combining algorithm identifiers are listed in Section B.11.

<Description> [Optional]

A fFree- form description of the policy.

<PolicyDefaults> [Optional]

Defines a set of default values applicable to the policy. The scope of <PolicyDefaults> element is the enclosing policy.

<Target> [Required]

The <Target> element defines the applicability of a <Policy> to decision requests.

Defines <Policy> element applicability to the authorization request. The <Target> element MAY be declared by the creator of the <Policy> element, or it MAY be computed from the <Target> elements of the referenced <Rule> elements either as an intersection or as a union.

<Rule> [Any Number]

A sequence of authorizations that MUST be combined according to the RuleCombiningAlgId attribute. Rules with <Target> elements matching authorization the decision request MUST be considered. Rules with <Target> elements that do not match authorization the decision request MUST NOT be considered. Applicability of rules to the authorization decision request is detailed in table xxxAppendix C.

<Obligations> [Optional]

A cConjunctive sequence of obligations that MUST be discharged by the PEP upon in conjunction with the authorization decision. If the PEP does not understand returned the obligations, then it MUST act as if the PDP denied access to the requested resource.

5.17. Element <Rule>The <Rule> element defines individual rules in the policy. The main components of this element are the <Target> and <Condition> elements, and the Effect attribute.

<xs:element name="Rule" type="xacml:RuleType"/><xs:complexType name="RuleType">

<xs:sequence><xs:element ref="xacml:Description" minOccurs="0"/><xs:element ref="xacml:Target" minOccurs="0"/><xs:element ref="xacml:Condition" minOccurs="0"/>

</xs:sequence><xs:attribute name="RuleId" type="xs:anyURI" use="required"/>


1934193519361937

1938

193919401941194219431944

1945

1946

1947

19481949

1950

1951

1952195319541955

1956

19571958195919601961

1962

196319641965

1966

1967196819691970197119721973197419751976

50

<xs:attribute name="Effect" type="xacml:EffectType" use="required"/></xs:complexType>

The <Rule> element is of RuleType complex type.

The <Rule> element contains the following attributes and elements:

RuleId

A URN identifying this rule.

Effect

Rule effect. Values of this attribute are either “Permit” or “Deny”.

<Description> [optional]

A fFree- form description of the rule.

<Target> [optional]

Identifies the set of decision requests that the <Rule> element is intended to evaluate. If this element is omitted, then the target for the <Rule> is defined by the enclosing <Policy> element. See Ssection 5.45.x for details.

<Condition> [optional]

A set of conditions predicate that MUST be satisfied for the rule to be applicableassigned its Effect value. A cCondition is a boolean function over a combination of subject, resource, or and environment attributes or other functions.

5.18. Simple tType EffectTypeThe EffectType simple type defines the values allowed for the Effect attribute of the <Rule> element and for the FulfillOn attribute of the <Obligation> element.

<xs:simpleType name="EffectType"><xs:restriction base="xs:string">

<xs:enumeration value="Permit"/><xs:enumeration value="Deny"/>

</xs:restriction></xs:simpleType>

5.19. Element <Condition>The <Condition> element is a boolean function over subject, resource, action, or and environment attributes or functions of attributes. If the <Condition> element evaluates to "Ttrue", then the enclosing <Rule> element is applicable to the requestassigned its Effect value.

<xs:element name="Condition" type="xacml:ApplyType"/>

The <Condition> element if of ApplyType complex type.

5.20. Element <Apply>The <Apply> element denotes application of a function to its arguments, thus encoding a function call. The <Apply> element can be applied to any combination of <Apply>,


197719781979

1980

1981

1982

1983

1984

1985

1986

1987

1988

198919901991

1992

199319941995

1996

19971998199920002001200220032004

2005

2006200720082009

2010

2011

20122013

51

<AttributeValue>, <SubjectAttributeDesignator>, <SubjectAttributeDesignatorWhere>, <ResourceAttributeDesignator>, <ActionAttributeDesignator>, <EnvironmentAttributeDesignator> and <AttributeSelector> arguments.

<xs:element name="Apply" type="xacml:ApplyType"/><xs:complexType name="ApplyType">

<xs:choice minOccurs="0" maxOccurs="unbounded"><xs:element ref="xacml:Apply"/><xs:element ref="xacml:AttributeValue"/><xs:element ref="xacml:SubjectAttributeDesignatorWhere"/><xs:element ref="xacml:SubjectAttributeDesignator"/><xs:element ref="xacml:ResourceAttributeDesignator"/><xs:element ref="xacml:ActionAttributeDesignator"/><xs:element ref="xacml:EnvironmentAttributeDesignator"/><xs:element ref="xacml:AttributeSelector"/>

</xs:choice><xs:attribute name="FunctionId" type="xs:QName" use="required"/>

</xs:complexType>

The <Apply> element is of ApplyType complex type. The top-level element of the ApplyType is a <Condition> element described in Ssection 5.195.19.

The <Apply> element contains the following attributes and elements:

FunctionId [Required]

The QName of a function. Xacml-defined functions are described in the accompanying Table xxAppendix A.

<Apply> [Optional]

A nNested function- call argument.

<AttributeValue> [Optional]

A lLiteral value argument.

<SubjectAttributeDesignatorWhere>

A sSubject attribute argument.

<SubjectAttributeDesignator> [Optional]

A sSubject attribute argument.

<ResourceAttributeDesignator> [Optional]

A rResource attribute argument.

<ActionAttributeDesignator> [Optional]

An action attribute argument.

<EnvironmentAttributeDesignator> [Optional]

An eEnvironment attribute argument.

<AttributeSelector> [Optional]

An attribute selector argument.


201420152016201720182019202020212022202320242025202620272028202920302031

20322033

2034

2035

20362037

2038

2039

2040

2041

2042

2043

2044

2045

2046

2047

2048

2049

2050

2051

2052

2053

52

5.21. Complex type AttributeDesignatorTypeElements of the AttributeDesignatorType complex type are used as a pointing devices into various portions elements of the <xacml-context:Request> element. <AttributeDesignatorType> is an XML syntax alternative toto the xpath expressions used by the <AttributeSelector> element.

Elements of <AttributeDesignatorType> type select a set of attributes from the request context, each of them having the same AttributeId value. In thatAs such, the attribute designator semantics is are identical to those of an xpath path expressions.

<xs:complexType name="AttributeDesignatorType"><xs:attribute name="AttributeId" type="xs:anyURI"

use="required"/><xs:attribute name="DataType" type="xs:anyURI" use="required"/><xs:attribute name="Issuer" type="xs:anyURI" use="optional"/>

</xs:complexType>

The <AttributeDesignatorType> contains the following attributes:

AttributeId [Required]

The aAttribute identifier selecting an attribute within the <xacml-context:Request> element.

DataType [Required]

The dData type for interpreting the corresponding attribute value in the <xacml-context:Request> element.

Issuer [Optional]

The aAuthority that issued the attribute.

5.22. Element <SubjectAttributeDesignator>The <SubjectAttributeDesignator> element selects a set of subject attribute values having the same attribute identifier from within all <Ssubject> elements sections of the <xacml-context:Request> element. In thatAs such, the <SubjectAttributeDesignator> element behaves like an xpath path expression.

Note that because the <xacml-context:Request> element MAY have multiple <xacml-context:Subject> elements, attribute values from all of them are selected. The <SubjectAttributeDesignatorWhere> element provides a way to narrow down this selection to the a specific subject.

The <SubjectAttributeDesignator> element is used by the <SubjectMatch> element and can be passed to the <Apply> element as an argument.

<xs:element name="SubjectAttributeDesignator" type="xacml:AttributeDesignatorType"/>

The <SubjectAttributeDesignator> element is of AttributeDesignatorType complex type.

5.23. Element <ResourceAttributeDesignator>The <ResourceAttributeDesignator> element selects a set of resource attribute values having the same attribute identifier from within <Rresource> section element of the <xacml-


2054

2055205620572058

205920602061

206220632064206520662067

2068

2069

2070

2071

20722073

2074

2075

2076

2077207820792080

2081208220832084

2085208620872088

2089

2090

20912092

53

context:Request> element. In thatAs such, the <ResourceAttributeDesignator> element behaves like an xpath path expression.

The <ResourceAttributeDesignator> element is used by the <ResourceMatch> element and can be passed to the <Apply> element as an argument.

<xs:element name="ResourceAttributeDesignator" type="xacml:AttributeDesignatorType"/>

The <ResourceAttributeDesignator> element is of AttributeDesignatorType complex type.

5.24. Element <ActionAttributeDesignator>The <ActionAttributeDesignator> element selects a set of action attribute values having the same attribute identifier from within the <Aaction> section element of the <xacml-context:Request> element. In thatAs such, the <ActionAttributeDesignator> element behaves like an xpath path expression.

The <ActionAttributeDesignator> element is used by the <ActionMatch> element and can be passed to the <Apply> element as an argument.

<xs:element name="ActionAttributeDesignator" type="xacml:AttributeDesignatorType"/>

The <ActionAttributeDesignator> element is of AttributeDesignatorType complex type.

5.25. Element <EnvironmentAttributeDesignator>The <EnvironmentAttributeDesignator> element selects a set of environment attribute values having the same attribute identifier from within the <Eenvironment> section element of the <xacml-context:Request> element. In thatAs such, the <EnvironmentAttributeDesignator> element behaves like an xpath path expression.

The <EnvironmentAttributeDesignator> element can be passed to the <Apply> element as an argument.

<xs:element name="EnvironmentAttributeDesignator" type="xacml:AttributeDesignatorType"/>

The <EnvironmentAttributeDesignator> element is of AttributeDesignatorType complex type.

5.26. Element <SubjectAttributeDesignatorWhere>The element <SubjectAttributeDesignatorWhere> allows to specifiesy additional subject matches when a subject attribute value is selected from the <xacml-contex:Request> element.

Because the <xacml-context:Request> element MAY contain multiple <xacml-context:Subject> elements, the <SubjectAttributeDesignatorWhere> element provides a way to focus the subject attribute selection on a particular subject.

The <SubjectAttributeDesignatorWhere> element is designed to make Complex selections such as: Select the attribute value for the subject attribute whose id is “A”, such, that the attribute value for the subject attribute whose id is “B” is “valueB” and the attribute value for the subject attribute whose id is “C” is “valueC”.


20932094

2095209620972098

2099

2100

2101210221032104

2105210621072108

2109

2110

2111211221132114

21152116

21172118

21192120

2121

212221232124

212521262127

2128212921302131

54

Every subject match narrows down a set of attributes selected by the previous match.

Element <SubjectAttributeDesignatorWhere> is passed as an argument to the <Apply> element.

<xs:element name="SubjectAttributeDesignatorWhere" type="xacml:SubjectAttributeDesignatorWhereType"/>

<xs:complexType name="SubjectAttributeDesignatorWhereType"><xs:complexContent>

<xs:extension base="xacml:AttributeDesignatorType"><xs:sequence>

<xs:element ref="xacml:SubjectMatch" minOccurs="0"/></xs:sequence>

</xs:extension></xs:complexContent>

</xs:complexType>

The <SubjectAttributeDesignatorWhere> element is of SubjectAttributeDesignatorWhereType complex type.

In addition to its base type, the <SubjectAttributeDesignatorWhere> element contains the following elements:

<SubjectMatch> [Any Number]

A conjunctive sequence of matches against the <Ssubject> portion element of the

<xacml-context:Request> element. Each subject match in a sequence narrows down a set of subject attributes selected by the previous match.

5.27. Element <AttributeSelector>The <AttributeSelector> element is a free- form pointing device into the <xacml-context:Request> element. It is usinguses xpath syntax to select elements from the request context. There are no restrictions on the xpath. However, the fFull power of the xpath syntax should be used with care: a. P policy writer MUST ensure that, when the <AttributeSelector> element is used in place of one of the elements of type any element of <AttributeDesignatorType>, it is pointing to the correct section of the <xacml-context:Request> element. Support for the <AttributeSelector> element is OPTIONAL.

<xs:element name="AttributeSelector" type="xacml:AttributeSelectorType"/><xs:complexType name="AttributeSelectorType"><xs:attribute name="RequestContextPath" type="xs:anyURI"

use="required"/><xs:attribute name="DataType" type="xs:anyURI" use="required"/><xs:attribute name="XPathVersion" type="xs:anyURI" use="optional"/>

</ xs:complexType>

The <AttributeSelector> element is of <AttributeSelectorType> complex type.

The <AttributeSelector> element has the following attributes:

RequestContextPath [Required]

An Xpath expression into the request context. There is no restriction on the xpath syntax.

DataType [Required]


2132

21332134

213521362137213821392140214121422143214421452146

21472148

21492150

2151

2152

21532154

2155

215621572158215921602161216221632164216521662167216821692170

2171

2172

2173

2174

2175

55

The dData type of the selected item. It could be an built-inxml- schema- defined data type or any other derived data type.

XpathVersion [Optional]

Xpath version. The dDefault value for this attribute is: http://www.w3.org/TR/1999/Rec-xpath-19991116, which is xpath 1.0. It could be overwritten by another value or by the <XpathVersion> element of the <PolicySetDefaults> element..

5.28. Element <AttributeValue>The <AttributeValue> element contains a literal attribute value. The type of the value MUST be contained in the DataType attribute.

<xs:element name="AttributeValue" type="xacml:AttributeValueType"/><xs:complexType name="AttributeValueType">

<xs:complexContent><xs:extension base="xs:anyType">

<xs:attribute name="DataType" type="xs:anyURI" use="required"/>


</xs:complexType>

The <AttributeValue> element is of AttributeValueType complex type.

The <AttributeValue> element contains the following attributes:

DataType [required]

The type of the value. The attribute MAY be of one of the xmlschema- embedded defined types. Alternatively, it MAY be of a structured type defined in some other namespace.

5.29. Element <Obligations>The <Obligations> element contains a set of <Obligation> elements. A PEP MUST fulfill all obligations returned by the PDP. If a PEP does not understand an obligation, then it MUST act as if the PDP had returned a “Deny” authorization decision.

<xs:element name="Obligations" type="xacml:ObligationsType"/><xs:complexType name="ObligationsType"><xs:sequence>

<xs:element ref="xacml:Obligation" maxOccurs="unbounded"/></xs:sequence>

</xs:complexType>

The <Obligations> element is of ObligationsType complexType.

<Obligation> [One to Many]

A sequence of obligations that MUST be fulfilled by the PEP. If the PEP does not understand an obligation, then it MUST act as if the PDP had returned a “Deny” authorization decision.


21762177

2178

217921802181

2182

21832184218521862187218821892190219121922193

2194

2195

2196

219721982199

2200

220122022203

220422052206220722082209

2210

2211

221222132214

56

http://www.w3.org/TR/1999/Rec-xpath-19991116

http://www.w3.org/TR/1999/Rec-xpath-19991116

5.30. Element <Obligation>The <Obligation> element contains an identifier for the obligation and a set of attributes that form arguments of the action defined by the obligation. The FulfillOn attribute indicates the decision value for which this obligation MUST be fulfilled.

<xs:element name="Obligation" type="xacml:ObligationType"/><xs:complexType name="ObligationType"><xs:choice maxOccurs="unbounded">

<xs:element ref="xacml:AttributeAssignment"/></xs:choice><xs:attribute name="ObligationId" type="xs:anyURI" use="required"/><xs:attribute name="FulfilOn" type="xacml:EffectType"


The <Obligation> element is of ObligationType complexType.

The ObligationId [required]

Obligation identifier. The value of the obligation identifier is interpreted by the PEP.

FulfillOn [required]

The dDecision value for which this obligation MUST be fulfilled.

<AttributeAssignment> [required]

Obligation arguments assignment. The vValues of the obligation arguments are interpreted by the PEP.

5.31. Element <AttributeAssignment>The <AttributeAssignment> element contains an AttributeId and the corresponding attribute value and AttributeId. The AttributeId is part of attribute meta-data, and is used when the attribute can not be referenced by it’s location in the <xacml-context:Request>. This situation may arise in an <Obligation> element if the obligation has includes parameters.

<xs:element name="AttributeAssignment" type="xacml:AttributeAssignmentType"/><xs:complexType name="AttributeAssignmentType">

<xs:complexContent><xs:extension base="xacml:AttributeValueType">

<xs:attribute name="AttributeId" type="xs:anyURI" use="required"/>


</xs:complexType>

The <AttributeAssignment> element is of AttributeAssignmentType complex type.


The aAttribute Identifier

DataType [Required]

The dData type for the assigned value.


2215

221622172218

221922202221222222232224222522262227

2228

2229

2230

2231

2232

2233

22342235

2236

22372238223922402241224222432244224522462247224822492250

2251

2252

2253

2254

2255

57

6. Context sSyntax (normative with the exception of the schema fragments)

6.1. Element <Request>The <Request> element is a top-level element in the XACML context schema. A <Request> element is an abstraction layer used by the policy language. Any proprietary system using the XACML specification MUST transform its input into the xacml context request form.

The <Request> element consists of four sections denoted by the <Subject>, <Resource>, <Action>, and <Environment> elements. Each section contains a sequence of xacml context <Attribute> elements associated with the subject, resource, action, and environment respectively. Each section has a number of predefined attributes that MUST be included in the request context upon construction.

<xs:element name="Request" type="xacml-context:RequestType"/><xs:complexType name="RequestType">

<xs:sequence><xs:element ref="xacml-context:Subject"

maxOccurs="unbounded"/><xs:element ref="xacml-context:Resource"/><xs:element ref="xacml-context:Action"/><xs:element ref="xacml-context:Environment" minOccurs="0"/>


Element The <Request> element is of RequestType complex type.

The <Request> element contains the following elements:

<Subject> [One to Many]

Identifies a subject of in the request context. One or more <Subject> elements are allowed. Each <Subject> element MUST contain a number of predefined <Attribute> elements. It MAY contain additional <Attribute> elements.

[Issue: list required attributes]

<Resource> [Required]

Contains information about the resource for to which access is being requested. It MAY

include a <ResourceContent> element, and it MUST contain a number of predefined <Attribute> elements. Additional <Attribute> elements MAY be included.

[Issue: list required attributes]

<Action> [Required]

Identifies the requested action by listing a set of <Attribute> elements associated with the action.

<Environment> [Optional]

Contains a set of <Attribute> elements of the environment. These <Attribute> elements MAY form a part of policy evaluation.


2256

2257

2258

225922602261

22622263226422652266

2267226822692270227122722273227422752276

2277

2278

2279

228022812282

2283

2284

2285

22862287

2288

2289

22902291

2292

22932294

58

6.2. Element <Subject>The <Subject> element specifies a subject of a decision request context by listing a sequence of <Attribute> elements associated with the subject.

<xs:element name="Subject" type="xacml-context:SubjectType"/><xs:complexType name="SubjectType">

<xs:sequence><xs:element ref="xacml-context:Attribute" minOccurs="0"

maxOccurs="unbounded"/></xs:sequence>

</xs:complexType>

The <Subject> element is of SubjectType complex type.

<Attribute> [Any Number]

A sequence of attributes that apply toassociated with the subject. A number of attributes MUST be present for each <Subject> element upon construction of the request context.

[Issue: Describe required attributes]

6.3. Element <Resource>The <Resource> element encapsulates the requested resource and lists a sequence of <Attribute> elements associated with that resource and optional resource content.

<xs:element name="Resource" type="xacml-context:ResourceType"/><xs:complexType name="ResourceType">

<xs:sequence><xs:element ref="xacml-context:ResourceContent"

minOccurs="0"/><xs:element ref="xacml-context:Attribute" minOccurs="0"


</xs:complexType>

The <Resource> element is of ResourceType complex type.

The <Resource> element contains the following elements:

<ResourceContent> [Optional]

Placeholder for tThe resource content.


A sequence of resource attributes. A number of <Attribute> elements MUST be included. Additional <Attribute> elements MUST MAY be present.

6.4. Element <ResourceContent>The <ResourceContent> element is a notional placeholder for the resource content. If an xacml policy needs access toreferences the contents of thea resource, then the <ResourceContent> element is used as thea reference point.

<xs:complexType name="ResourceContentType"><xs:sequence>


2295

229622972298229923002301230223032304

2305

2306

23072308

2309

2310

23112312231323142315231623172318231923202321

2322

2323

2324

2325

2326

23272328

2329

233023312332

23332334

59

<xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence><xs:anyAttribute namespace="##any" processContents="lax"/>

</xs:complexType>

The <ResourceContent> element is of ResourceContentType complex type.

The <ResourceContent> element allows arbitrary elements and attributes.

6.5. Element <Action>The <Action> element identifies the requested action by listing a set of <Attribute> elements associated with the action.

<xs:element name="Action" type="xacml-context:ActionType"/><xs:complexType name="ActionType">



</xs:complexType>

The <Action> element is of ActionType complex type.

The <Attribute> [Any Number]

Action attributes.

6.6. Element <Environment>The <Environment> element contains a set of attributes of the environment. These attributes MAY form part of policy evaluation.

<xs:element name="Environment" type="xacml-context:EnvironmentType"/><xs:complexType name="EnvironmentType">



</xs:complexType>

The <Environment> element is of EnvironmentType complex type.

The <Environment> element contains the following elements:


A lList of environment attributes. Environment attributes are attributes that are not associated with either the subject, resource, or action.

6.7. Element <Attribute>The <Attribute> element is a central abstraction of the request context. It contains an attribute value and attribute meta-data. The aAttribute meta-data is comprises the attribute identifier, attribute issuer, and attribute issue instant. Attribute designators and attribute selectors in the policy refer to attributes by this meta-data.


23352336233723382339

2340

2341

2342

23432344

2345234623472348234923502351

2352

2353

2354

2355

23562357

23582359236023612362236323642365

2366

2367

2368

23692370

2371

2372237323742375

60

<xs:element name="Attribute" type="xacml-context:AttributeType"/><xs:complexType name="AttributeType">

<xs:sequence><xs:element ref="xacml-context:AttributeValue" minOccurs="0"

maxOccurs="unbounded"/></xs:sequence><xs:attribute name="AttributeId" type="xs:anyURI"

use="required"/><xs:attribute name="Issuer" type="xs:string" use="optional"/><xs:attribute name="IssueInstant" type="xs:dateTime"

use="optional"/></xs:complexType>

The <Attribute> element is of AttributeType complex type.

The <Attribute> element contains the following attributes and elements:


Attribute identifier. A number of identifiers are reserved by the XACML to denote commonly used attributes.

Issuer [Optional]

Attribute issuer. This It MAY be a URI, and that binds to a public key, or some other identifier exchanged out- of- band by issuing and relying parties.

IssueInstant [Optional]

Attribute issue instant.

6.8. Element <AttributeValue>The <AttributeValue> element is acontains the value of an attribute.

<xs:element name="AttributeValue" type="xs:anyType"/>

The <AttributeValue> element is of xs:anyType type.

6.9. Element <Response>The <Response> element encapsulates the authorization decision returned by the PDP. It includes a sequence of one or more results with one <Result> element per requested resource. Multiple results MAY be returned when the value of the “urn:oasis:xacml:1.0:resource:scope” resource attribute in the request context is “Ddescendants”. Support for multiple results is OPTIONAL.

<xs:element name="Response" type="xacml-context:ResponseType"/><xs:complexType name="ResponseType">

<xs:sequence><xs:element ref="xacml-context:Result"


</xs:complexType>

The <Response> element is of ResponseType complex type.

The <Response> element contains the following elements:

<Result> [One to Many]


237623772378237923802381238223832384238523862387

2388

2389

2390

23912392

2393

23942395

2396

2397

2398

23992400

2401

2402

24032404240524062407

2408240924102411241224132414

2415

2416

2417

61

An authorization decision result.

6.10. Element <Result>The <Result> element represents an authorization decision result for the resource specified by the ResourceURI attribute. It MAY include a set of obligations that MUST be fulfilled by the PEP. If the PEP does not understand an obligation, then it MUST act as if the PDP had denied access to the requested resource.

<xs:element name="Result" type="xacml-context:ResultType"/><xs:complexType name="ResultType">

<xs:sequence><xs:element ref="xacml-context:Decision"/><xs:element ref="xacml-context:Status" minOccurs="0"/><xs:element ref="xacml:Obligations" minOccurs="0"/>

</xs:sequence><xs:attribute name="ResourceURI" type="xs:anyURI"

use="optional"/></xs:complexType>

The <Result> element is of ResultType complex type.

The <Result> element contains following the following attributes and elements:

ResourceURI [Optional]

Resource The URI for the requested resource. If this attribute is omitted, then the resource URI is specified by the “urn:oasis:names:tc:xacml:1.0:resource:resource-uri” resource attribute in the <Request> element.

<Decision> [Required]

The aAuthorization decision

<Status> [Optional]

Indicates whether the request succeeded or not.

<xacml:Obligations> [Optional]

A list of obligations that MUST be discharged by the PEP. If the PEP does not understand an obligation, then it MUST act as if the PDP had denied access to the requested resource. See section 5.30 for <xacml:Obligations> element.

6.11. Element <Decision>The <Decision> element contains the result of policy evaluation.

<xs:element name="Decision" type="xacml-context:DecisionType"/><xs:simpleType name="DecisionType">

<xs:restriction base="xs:string"><xs:enumeration value="Permit"/><xs:enumeration value="Deny"/><xs:enumeration value="Indeterminate"/><xs:enumeration value="NotApplicable"/>

</xs:restriction></xs:simpleType>

The <Decision> element is of DecisionType simple type.


2418

2419

2420242124222423

2424242524262427242824292430243124322433

2434

2435

2436

243724382439

2440

2441

2442

2443

2444

244524462447

2448

2449245024512452245324542455245624572458

2459

62

6.12. Element <Status>The <Status> element represents the status of the authorization decision result.

<xs:element name="Status" type="xacml-context:StatusType"/><xs:complexType name="StatusType">

<xs:sequence><xs:element ref="xacml-context:StatusCode"/><xs:element ref="xacml-context:StatusMessage" minOccurs="0"/><xs:element ref="xacml-context:StatusDetail" minOccurs="0"/>


The <Status> element is of StatusType complex type.

The <Status> element contains the following elements:

<StatusCode> [Required]

Status code.

<StatusMessage> [Optional]

A sStatus message describing the status code.

<StatusDetail> [Optional]

Additional status information.

6.13. Element <StatusCode>The <StatusCode> element contains a major status code value and an optional sequence of minor status codes.

<xs:element name="StatusCode" type="xacml-context:StatusCodeType"/><xs:complexType name="StatusCodeType">

<xs:sequence><xs:element ref="xacml-context:StatusCode" minOccurs="0"/>

</xs:sequence><xs:attribute name="Value" type="xs:QName" use="required"/>

</xs:complexType>

The <StatusCode> element is of StatusCodeType complex type.

The <StatusCode> element contains the following attributes and elements:

Value [Required]

See Section B.10 for a list of values.

tatus code value. In case of success this value MUST be set to “urn:oasis:names:tc:xacml:1.0:status:ok”.

[Issue: are those q-names?]

[Issue: when to use

urn:oasis:names:tc:xacml:1.0:status:processing-error

urn:oasis:names:tc:xacml:1.0:status:syntax-error]

<StatusCode> [Any Number]


2460

246124622463246424652466246724682469

2470

2471

2472

2473

2474

2475

2476

2477

2478

24792480

2481248224832484248524862487

2488

2489

2490

2491

24922493

2494

2495

2496

2497

2498

63

Minor status code. This status code qualifies its parent status code.

6.14. Element <StatusMessage>The <StatusMessage> element is a free- form description of the status code.

<xs:element name="StatusMessage" type="xs:string"/>

The <StatusMessage> element is of xs:string type.

6.15. Element <StatusDetail>The <StatusDetail> element qualifies the <Status> element with additional information.

<xs:element name="StatusDetail" type="xacml-context:StatusDetailType"/><xs:complexType name="StatusDetailType">

<xs:sequence><xs:any namespace="##any" processContents="lax" minOccurs="0"


</xs:complexType>

The <StatusDetail> element is of StatusDetailType complex type.

The <StatusDetail> element allows arbitrary xml content.


2499

2500

25012502

2503

2504

250525062507250825092510251125122513

2514

2515

64

7. Profiles (normative but not mandatory to implement)

7.1. SAML

7.1.1 XSLT transformation for generating XACML Request Context from SAML Request

[7.1.2] XSLT transformation reads SAML Request as an input and generates XACML Request Context as an output.

7.1.2[7.1.3] <xsl:stylesheet version = '1.0' xmlns:xsl='http://www.w3.org/1999/XSL/Transform' xmlns:xac='urn:oasis:names:tc:xacml:0.16g:context' xmlns:saml='urn:oasis:names:tc:SAML:1.0:assertion' xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:tc:xacml:0.16g:context draft-xacml-schema-context-16g.xsd urn:oasis:names:tc:SAML:1.0:protocol cs-sstc-schema-protocol-01.xsd urn:oasis:names:tc:SAML:1.0:assertion cs-sstc-schema-assertion-01.xsd">

7.1.3[7.1.4]

7.1.4[7.1.5] <xsl:template match="samlp:Request">

7.1.5[7.1.6] <xac:Request xmlns="urn:oasis:names:tc:xacml:0.16g:context" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:tc:xacml:0.16g:context draft-xacml-schema-context-16g.xsd urn:oasis:names:tc:SAML:1.0:protocol cs-sstc-schema-protocol-01.xsd urn:oasis:names:tc:SAML:1.0:assertion cs-sstc-schema-assertion-01.xsd">

7.1.6[7.1.7] <xsl:apply-templates select="samlp:AuthorizationDecisionQuery/saml:Subject"/>


2516

2517

2518

25192520

25212522

25232524252525262527252825292530253125322533

2534

2535

2536253725382539254025412542254325442545

25462547

65

7.1.7[7.1.8] <xsl:apply-templates select="samlp:AuthorizationDecisionQuery"/>

7.1.8[7.1.9] <xsl:apply-templates select="samlp:AuthorizationDecisionQuery/saml:Action"/>

7.1.9[7.1.10] </xac:Request>

7.1.10[7.1.11] </xsl:template>

7.1.11[7.1.12]

7.1.12[7.1.13] <xsl:template match="saml:NameIdentifier">

7.1.13[7.1.14] <xsl:element name="xac:Subject">

7.1.14[7.1.15] <xsl:element name="xac:Attribute">

7.1.15[7.1.16] <xsl:attribute name="AttributeId">

7.1.16[7.1.17] <xsl:text>urn:oasis:names:tc:xacml:1.0:subject:subject-id</xsl:text>

7.1.17[7.1.18] </xsl:attribute>

7.1.18[7.1.19] <xac:AttributeValue>

7.1.19[7.1.20] <xsl:value-of select="."/>

7.1.20[7.1.21] </xac:AttributeValue>

7.1.21[7.1.22] </xsl:element>

7.1.22[7.1.23] <xsl:if test="@NameQualifier">




25482549

25502551

2552

2553

2554

2555

2556

2557

2558

25592560

2561

2562

2563

2564

2565

2566

2567

2568

66

7.1.25[7.1.26] <xsl:text>urn:oasis:names:tc:xacml:1.0:subject:subject-id-qualifier</xsl:text>

7.1.26[7.1.27] </xsl:attribute>


7.1.28[7.1.29] <xsl:value-of select="@NameQualifier"/>


7.1.30[7.1.31] </xsl:element>

7.1.31[7.1.32] </xsl:if>

7.1.32[7.1.33] <xsl:if test="@Format">



7.1.35[7.1.36] <xsl:text>Format</xsl:text>

7.1.36[7.1.37] </xsl:attribute>


7.1.38[7.1.39] <xsl:value-of select="@Format"/>


7.1.40[7.1.41] </xsl:element>

7.1.41[7.1.42] </xsl:if>

7.1.42[7.1.43] <xsl:if test="//saml:Evidence">



256925702571

2572

2573

2574

2575

2576

2577

2578

2579

2580

2581

2582

2583

2584

2585

2586

2587

2588

2589

67


7.1.45[7.1.46] <xsl:text>Evidence</xsl:text>

7.1.46[7.1.47] </xsl:attribute>


7.1.48[7.1.49] <xsl:copy-of select="//saml:Evidence"/>


7.1.50[7.1.51] </xsl:element>

7.1.51[7.1.52] </xsl:if>

7.1.52[7.1.53] </xsl:element>

7.1.53[7.1.54] </xsl:template>

7.1.54[7.1.55]

7.1.55[7.1.56] <xsl:template match="samlp:AuthorizationDecisionQuery">

7.1.56[7.1.57] <xac:Resource>



7.1.59[7.1.60] <xsl:text>urn:oasis:names:tc:xacml:1.0:resource:resource-uri</xsl:text>

7.1.60[7.1.61] </xsl:attribute>



2590

2591

2592

2593

2594

2595

2596

2597

2598

2599

2600

26012602

2603

2604

2605

260626072608

2609

2610

68

7.1.62[7.1.63] <xsl:value-of select="@Resource"/>


7.1.64[7.1.65] </xsl:element>

7.1.65[7.1.66] </xac:Resource>

7.1.66[7.1.67] </xsl:template>

7.1.67[7.1.68]

7.1.68[7.1.69] <xsl:template match="saml:Action">

7.1.69[7.1.70] <xac:Action>



7.1.72[7.1.73] <xsl:text>urn:oasis:names:tc:xacml:1.0:action</xsl:text>

7.1.73[7.1.74] </xsl:attribute>


7.1.75[7.1.76] <xsl:value-of select='.'/>


7.1.77[7.1.78] </xsl:element>

7.1.78[7.1.79] <xsl:if test="@Namespace">




2611

2612

2613

2614

2615

2616

2617

2618

2619

2620

26212622

2623

2624

2625

2626

2627

2628

2629

2630

69

7.1.81[7.1.82] <xsl:text>Namespace</xsl:text>

7.1.82[7.1.83] </xsl:attribute>

7.1.83[7.1.84] <xsl:element name="xac:AttributeValue">

7.1.84[7.1.85] <xsl:value-of select="@Namespace"/>

7.1.85[7.1.86] </xsl:element>

7.1.86[7.1.87] </xsl:element>

7.1.87[7.1.88] </xsl:if>

7.1.88[7.1.89] </xac:Action>

7.1.89[7.1.90] </xsl:template>

7.1.90[7.1.91]

7.1.91[7.1.92] </xsl:stylesheet>

7.1.92[7.1.93] XSLT transformation for generating SAML Response from XACML Response Context

[7.1.94] XSLT transformation that reads XACML Context as an input and generates SAML Response as an output.

7.1.93[7.1.95] "XACML-RequestResponse.xml" has a dummy root element <XACMLRequestResponse>

7.1.94[7.1.96] that has <Request> element and <Response> element that correspond to

7.1.95[7.1.97] "XACML-Request.xml" and "XACML-Response.xml", respectively.

7.1.96[7.1.98] "XACML-Response.xml" is valid against the XACML 0.16g context schema but


2631

2632

2633

2634

2635

2636

2637

2638

2639

2640

2641

26422643

26442645

26462647

26482649

26502651

26522653

70

7.1.97[7.1.99] the "SAML-Response.xml" is not valid against SAML 1.0 specification. It

7.1.98[7.1.100] does not include mandatory SAML attributes such as ResponseId and

7.1.99[7.1.101] MajorVersion attributes in the Response element because the

7.1.100[7.1.102] "XACML-Response.xml" does not include such information. The XSLT

7.1.101[7.1.103] transformation just shows a rough idea on how to map XACML Context and SAML

7.1.102[7.1.104] assertion. Implementers who use SAML as a communication protocol must write

7.1.103[7.1.105] their own code that transforms a XACML Response into a SAML Response

7.1.104[7.1.106] instead of this XSLT transformation.

7.1.105[7.1.107] <xsl:stylesheet version = '1.0' xmlns:xsl='http://www.w3.org/1999/XSL/Transform' xmlns:xac='urn:oasis:names:tc:xacml:0.16g:context' xmlns:saml='urn:oasis:names:tc:SAML:1.0:assertion' xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:tc:xacml:0.16g:context draft-xacml-schema-context-16g.xsd urn:oasis:names:tc:SAML:1.0:protocol cs-sstc-schema-protocol-01.xsd urn:oasis:names:tc:SAML:1.0:assertion cs-sstc-schema-assertion-01.xsd">

7.1.106[7.1.108]

7.1.107[7.1.109] <xsl:template match="/">


26542655

26562657

26582659

26602661

26622663

26642665

26662667

2668

26692670267126722673267426752676267726782679

2680

2681

71

7.1.108[7.1.110] <samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xac='urn:oasis:names:tc:xacml:0.16g:context' xsi:schemaLocation="urn:oasis:names:tc:SAML:1.0:protocol cs-sstc-schema-protocol-01.xsd urn:oasis:names:tc:SAML:1.0:assertion cs-sstc-schema-assertion-01.xsd urn:oasis:names:tc:xacml:0.16g:context draft-xacml-schema-context-16g.xsd">

7.1.109[7.1.111] <xsl:apply-templates select="//xac:Result/xac:Status"/>

7.1.110[7.1.112] <xsl:apply-templates select="//xac:Result"/>

7.1.111[7.1.113] </samlp:Response>

7.1.112[7.1.114] </xsl:template>

7.1.113[7.1.115]

7.1.114[7.1.116] <xsl:template match="xac:Status">

7.1.115[7.1.117] <xsl:element name="samlp:Status">

7.1.116[7.1.118] <xsl:element name="samlp:StatusCode">

7.1.117[7.1.119] <xsl:attribute name="Value">

7.1.118[7.1.120] <xsl:value-of select="xac:StatusCode/@Value"/>

7.1.119[7.1.121] </xsl:attribute>

7.1.120[7.1.122] </xsl:element>

7.1.121[7.1.123] </xsl:element>

7.1.122[7.1.124] </xsl:template>

7.1.123[7.1.125]


268226832684268526862687268826892690

26912692

2693

2694

2695

2696

2697

2698

2699

2700

2701

2702

2703

2704

2705

2706

72

7.1.124[7.1.126] <xsl:template match="xac:Result">

7.1.125[7.1.127] <saml:Assertion>

7.1.126[7.1.128] <xsl:element name="saml:AuthorizationDecisionStatement">

7.1.127[7.1.129] <xsl:attribute name="Resource">

7.1.128[7.1.130] <xsl:value-of select="@ResourceURI"/>

7.1.129[7.1.131] </xsl:attribute>

7.1.130[7.1.132] <xsl:attribute name="Decision">

7.1.131[7.1.133] <xsl:value-of select="xac:Decision"/>

7.1.132[7.1.134] </xsl:attribute>

7.1.133[7.1.135] <xsl:apply-templates select="/" mode="Subject"/>

7.1.134[7.1.136] <xsl:apply-templates select="/" mode="Action"/>

7.1.135[7.1.137] <xsl:apply-templates select="xac:Obligations"/>

7.1.136[7.1.138] </xsl:element>

7.1.137[7.1.139] </saml:Assertion>

7.1.138[7.1.140] </xsl:template>

7.1.139[7.1.141]

7.1.140[7.1.142] <xsl:template match="xac:Obligations">

7.1.141[7.1.143] <xsl:element name="saml:Obligations">

7.1.142[7.1.144] <xsl:apply-templates select="xac:Obligation"/>


2707

2708

27092710

2711

2712

2713

2714

2715

2716

2717

2718

2719

2720

2721

2722

2723

2724

2725

2726

73

7.1.143[7.1.145] </xsl:element>

7.1.144[7.1.146] </xsl:template>

7.1.145[7.1.147]

7.1.146[7.1.148] <xsl:template match="xac:Obligation">

7.1.147[7.1.149] <xsl:copy-of select="."/>

7.1.148[7.1.150] </xsl:template>

7.1.149[7.1.151]

7.1.150[7.1.152] <xsl:template match="/" mode="Subject">

7.1.151[7.1.153] <xsl:apply-templates select="//xac:Request/xac:Subject"/>

7.1.152[7.1.154] </xsl:template>

7.1.153[7.1.155]

7.1.154[7.1.156] <xsl:template match="/" mode="Action">

7.1.155[7.1.157] <xsl:apply-templates select="//xac:Request/xac:Action"/>

7.1.156[7.1.158] </xsl:template>

7.1.157[7.1.159]

7.1.158[7.1.160] <xsl:template match="xac:Subject">

7.1.159[7.1.161] <xsl:element name="saml:Subject">

7.1.160[7.1.162] <xsl:element name="saml:NameIdentifier">


2727

2728

2729

2730

2731

2732

2733

2734

27352736

2737

2738

2739

27402741

2742

2743

2744

2745

2746

74

7.1.161[7.1.163] <xsl:apply-templates select="xac:Attribute[@AttributeId='urn:oasis:names:tc:xacml:1.0:subject:subject-id-qualifier']" mode="SubjectQualifier"/>

7.1.162[7.1.164] <xsl:apply-templates select="xac:Attribute[@AttributeId='urn:oasis:names:tc:xacml:1.0:subject:subject-id']" mode="SubjectId"/>

7.1.163[7.1.165] <xsl:apply-templates select="xac:Attribute[@AttributeId='format']" mode="SubjectFormat"/>

7.1.164[7.1.166] </xsl:element>

7.1.165[7.1.167] </xsl:element>

7.1.166[7.1.168] </xsl:template>

7.1.167[7.1.169]

7.1.168[7.1.170] <xsl:template match="xac:Attribute" mode="SubjectId">

7.1.169[7.1.171] <xsl:value-of select="xac:AttributeValue"/>

7.1.170[7.1.172] </xsl:template>

7.1.171[7.1.173]

7.1.172[7.1.174] <xsl:template match="xac:Attribute" mode="SubjectQualifier">

7.1.173[7.1.175] <xsl:attribute name="NameQualifier">


7.1.175[7.1.177] </xsl:attribute>

7.1.176[7.1.178] </xsl:template>

7.1.177[7.1.179] draft-xacml-specification-16.doc 75

274727482749

275027512752

27532754

2755

2756

2757

2758

27592760

2761

2762

2763

27642765

2766

2767

2768

2769

2770

75

7.1.178[7.1.180] <xsl:template match="xac:Attribute" mode="SubjectFormat">

7.1.179[7.1.181] <xsl:attribute name="Format">


7.1.181[7.1.183] </xsl:attribute>

7.1.182[7.1.184] </xsl:template>

7.1.183[7.1.185]

7.1.184[7.1.186] <xsl:template match="xac:Action">

7.1.185[7.1.187] <xsl:element name="saml:Action">

7.1.186[7.1.188] <xsl:apply-templates select="xac:Attribute[@AttributeId='Namespace']" mode="ActionNamespace"/>

7.1.187[7.1.189] <xsl:value-of select="xac:Attribute[@AttributeId='urn:oasis:names:tc:xacml:1.0:action']/xac:AttributeValue"/>

7.1.188[7.1.190] </xsl:element>

7.1.189[7.1.191] </xsl:template>

7.1.190[7.1.192]

7.1.191[7.1.193] <xsl:template match="xac:Attribute" mode="ActionNamespace">

7.1.192[7.1.194] <xsl:attribute name="Namespace">


7.1.194[7.1.196] </xsl:attribute>


27712772

2773

2774

2775

2776

2777

2778

2779

278027812782

278327842785

2786

2787

2788

27892790

2791

2792

2793

76

7.1.195[7.1.197] </xsl:template>

7.1.196[7.1.198]

7.1.197[7.1.199] </xsl:stylesheet>

[7.1.200] XML Digital SignatureDescribes how XACML instances shall be integrity-protected in the case where XML DSig is used. PAPs MAY sign XACML <Policy> elements. When a PAP combines <Policy> elements, it MAY sign the resulting <PolicySet> element.

8. Operational mModel (normative)This section describes the operational model for an XACML-based environment.

8.1. Policy Decision Point (PDP)Given a valid XACML policy or a policy set, a compliant XACML PDP MUST evaluate that statement in accordance to the semantics specified in Sections 5 and 6 when applied to a specific request context. The PDP MUST return a response context, with one value of "Permit", "Deny", "Indeterminate" or "NotApplicable".

If a "Permit" is returned, the PEP MAY permit access to the resource. If a "Deny" is returned, then the PEP shall deny access to the resource. If a "Permit" with one or more obligations is returned, then the PEP MAY permit access provided that every obligation is fulfilled successfully.

If a "Deny" with one or more obligations is returned, then the PEP shall "Deny" access but still fulfill the obligations. In the case that an obligation cannot be fulfilled, the PEP SHOULD raise an error. How the error is raised is out of the scope of XACML. In any case, the PDP MAY return additional information in the <statusCode> element in the response context. For a "Permit" decision, it MAY specify which rules were used in decision making.

If an "Indeterminate" decision value is returned, it means that the PDP could not make a decision. The PDP MAY return a decision of "indeterminate" with a status code of "urn:oasis:names:tc:xacml:1.0:missing-attribute", signifying that more information is needed. In this case, the decision MAY list the names of any attributes of the subject and the resource that are needed by the PDP to refine its decision. A PEP MAY resubmit a refined request context in response to a decision of "Indeterminate" with a status code of "urn:oasis:names:tc:xacml:1.0:missing-attribute", by adding attribute values for the attribute names that are listed in the response. When the PDP returns a decision of "Indeterminate", with a status code of "urn:oasis:names:tc:xacml:1.0:missing-attribute", a PDP MUST NOT list the names of any attribute of the subject or the resource of the request for which values were already supplied in the original request. Note, this requirement forces the PDP to eventually return a decision of "Permit", "Deny" or "Indeterminate" with some other reason, in response to successively-refined requests.

If "NotApplicable" is returned, then it means that the PDP's policy does not cover the request, implying that the PEP should ask another PDP.


2794

2795

2796

2797

279827992800

2801

2802

2803

2804280528062807

280828092810

28112812281328142815

2816281728182819282028212822282328242825282628272828

28292830

77

XACML does not assume how top-level XACML policies should be configured. For example, a top-level policy might be a <Policy> element containing a <Target> element that matches every request, or it might be a <Policy> element containing a <Target> element that matches only a specific subject.

8.2. Hierarchical ResourceIt is often the case that a resource is organized as a hierarchy (e.g. file system, XML document). Some applications may require access to an entire subtree of the resource. XACML allows the PEP (or Context Handler) to specify whether the access is just for a single resource or for a subtree below the specified resource. The latter is equivalent to repeating a single request for the entire subtree. When a request context contains a resource attribute of "urn:oasis:names:tc:xacml:1.0:resource:scope" with a value of "Immediate" or does not contain that attribute in the context, then it means that the access is just for a single resource specified by the ResourceId attribute.

When the "urn:oasis:names:tc:xacml:1.0:resource:scope" attribute specifies a value of "Children", it means that the access is for both a specified resource and its children resources. When the "urn:oasis:names:tc:xacml:1.0:resource:scope" attribute specifies a value of "Descendant", it means that the access is for both a specified resource and all the descendant resources. In the case of "Children" and "Descendant", the authorization decision MAY include multiple results for the multiple resources. An XACML response can contain multiple <Result> elements. In such case, the <Status> element SHOULD be included only in the first <Result> element (the remaining <Result> elements SHOULD NOT include the <Status> element). Note that the method by which the PDP finds out whether the resource is hierarchically organized or not is out of the scope of XACML.

8.3. Propagation through Data HierarchyWhen the resource is hierarchically organized, it is often the case that a rule associated to a certain resource node propagates down to the descendant nodes. The XACML rule-combining algorithm does not support such propagation with regard to rules. Policy writers who need propagation MUST implement their own local algorithm and specify the algorithm identifier in the RuleCombiningAlgId attribute.

Given a valid XACML "policy statement" or a "policy set statement", a compliant XACML PDP MUST evaluate that statement in accordance to the semantics specified in Sections 5, 6, and 7 when applied to a specific input context. The PDP MUST return an output context, with one value of "permit", "deny", or "indeterminate". The PDP MAY return decision of "indeterminate" with an error code of "insufficient information", signifying that more information is needed. In this case, the decision MAY list the names of any attributes of the subject and the resource that are needed by the PDP to refine its decision.

Decision Convergence A PEP MAY resubmit a refined request context in response to a decision of "indeterminate" with an error code of "insufficient information" by adding attribute values for the attribute names that are listed in the response.

When the PDP returns an decision of "indeterminate" with an error code of "insufficient information", a PDP MUST NOT list the names of any attribute of the subject or the resource of the request for which values were already supplied in the request. Note, this requirement forces the


2831283228332834

2835

28362837283828392840284128422843

2844284528462847284828492850285128522853

2854

28552856285728582859

2860286128622863286428652866

2867

286828692870

287128722873

78

PDP to eventually return a decision of "permit", "deny", or "indeterminate" with some other reason, in response to successively-refined requests.

9. XACML extensibility points (non-normative)Describes the points within the XACML model and schema where extensions can be added

9.1. URIsThe following XML attributes are URIs.

Function,

ruleCombiningAlgId,

policyCombiningAlgId,

AttributeNameSpace and

AttributeName.

10. Security and privacy considerations (non-normative)

This section identifies possible security and privacy vulnerabilities that should be considered when implementing an XACML-based system. This section is strictly informative. It has been left to the implementers to assess whether these vulnerabilities apply to their environment and to select the appropriate safeguards.

10.1. Authentication Authentication here means the ability of one party in a transaction to determine the identity of the other party in the transaction. Authentication may be in one direction, or it may be bilateral1 .

Given the sensitive nature of access-control systems, it is important for a PEP to authenticate the identity of the PDP to which it sends decision requests. Otherwise, there is a risk that another process could provide false or invalid authorization decisions and compromise security of the access-control system.

It is equally important for a PDP to authenticate the identity of its clients and assess the level of trust to determine what, if any, sensitive data should be passed. One should keep in mind that even simple p\"Permit" or "Deny" responses could be exploited if someone was allowed to make unlimited requests to a PDP.

Many different techniques may be used to provide this authentication, such as co-located code, a private network, a VPN, or digital signatures. Authentication may also be done as part of the

1 Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) section 4.1


28742875

2876

2877

2878

2879

2880

2881

2882

2883

2884

2885

2886

2887288828892890

2891

28922893

2894289528962897

2898289929002901

29022903

7980

81

communication protocol used to exchange the contexts. In this case, the authentication may be performed at the message level or at the session level.

10.2. Confidentiality Confidentiality means that the contents of a message can be read only by the desired recipients and not by anyone else who encounters the message while it is in transit2 . There are two areas in which confidentiality should be considered: one is confidentiality during transmission; the other is confidentiality within a <policy> element.

10.3. Communication Confidentiality In some environments it will be deemed good practice to treat all data within an access-control system as confidential. In other environments, policies will be made freely available for distribution, inspection and audit. The idea behind keeping policy information secret is to make it more difficult for an attacker to know what steps might be sufficient to obtain unauthorized access. Regardless of the approach chosen, the security of the authorization system should not depend on the secrecy of the policy.

Any security concerns or requirements related to transmitting or exchanging XACML <policy> elements are outside the scope of the XACML standard. While it is often important to ensure that the integrity and confidentiality of <policy> elements is maintained when they are exchanged between two parties, it is left to the implementers to determine the appropriate mechanisms for their environment.

10.4. Statement Level Confidentiality In some cases, an implementation may want to encrypt only parts of an XACML policy.

The XML Encryption Syntax and Processing Candidate Recommendation from W3C can be used to encrypt all or parts of an XML document. This specification is recommended for use with XACML.

It should go without saying that if a repository is used to facilitate the communication of cleartext (i.e., unencrypted) policy between the PAP and PDP, then a secure repository should be used to store this sensitive data.

10.5. Policy IntegrityThe XACML policy, used by the PDP to evaluate the request context, is the heart of the system. There are two aspects in maintaining the integrity of the policy. One is to ensure that <policy> elements have not been altered since they were originally written or generated by the PAP. The other is to ensure that <policy> elements have not been inserted or deleted from the set of policies.

In many cases, both aspects can be achieved by ensuring the integrity of the systems and implementing session-level techniques to secure the communication between parties. The selection of the appropriate techniques has been left to the implementers.

However, when policy is distributed between organizations to be acted on at a later time, or when the policy travels with data, it would be useful to have a digital signature of the policy included with

2 Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) section 4.


29042905

2906

2907290829092910

2911

291229132914291529162917

29182919292029212922

2923

2924

292529262927

292829292930

2931

29322933293429352936

293729382939

29402941

8283

84

the policy statements. In these cases, the XML Signature Syntax and Processing standard from W3C is recommended to be used with XACML.

Digital signatures SHOULD only be used to ensure the integrity of the statements. Digital signatures SHOULD NOT be use as a method of selecting or evaluating policy. The PDP SHOULD NOT request a policy based on who signed the policy or whether or not it had been signed (as such a basis for selection would, itself, be a matter of policy). However, the PDP MUST verify that the key used to sign the policy is one controlled by the purported issuer of the policy. The means to do this are dependent on the specific signature technology chosen and are outside the scope of this document.

10.6. Policy IdentifiersSince policies can be referenced by their identifiers, it is the responsibility of the PAP to ensure that these are unique. Confusion between identifiers could lead to the enforcement of inappropriate policies. This specification is silent on whether a PAP must generate a new identifier when a policy is modified or may reuse an identifier. This is a matter of administrative practice. However, care must be taken in either case. If the identifier is reused, there is a danger that other policies or policy sets that reference it may be adversely affected. Conversely, if a new identifier is used, these other policies may continue to use the prior policy, unless it is erased. In either case the results may not be what the policy administrator intends.

10.7. Trust ModelDiscussions of authentication, integrity, and confidentiality mechanisms necessarily assume an underlying trust model: how can one entity come to believe that a given key is uniquely associated with a specific, identified entity so that the key can be used to encrypt data for that entity or verify signatures (or other integrity structures) from that entity? Many different types of trust model exist, including strict hierarchies, distributed authorities, the Web, the bridge and so on.

It is worth considering the relationships between the various entities of the authorization system in terms of the interdependencies that do and do not exist.

None of the entities of the authorization system are dependent on the system entity making the decision request. They may collect data from this entity, for example authentication, but are responsible for verifying it.

The correct operation of the system depends on the ability of the PEP to actually enforce policy decisions.

The PEP depends on the PDP to correctly evaluate policies. This in turn implies that the PDP is supplied with the correct inputs. Other than that, the PDP does not depend on the PEP.

The PDP depends on the PAP to supply appropriate policies. The PAP is not dependent on other components.

10.8. PrivacyIt is important to be aware that any transactions that occur with respect to access control may reveal private information about the participants. For example, if an XACML policy states that certain data may only be read by individuals with “Gold Card Member” status, then any transaction in which an entity is given access to that data leaks information to external observers about that entity’s status. Privacy considerations may therefore lead to encryption and/or to access control policies surrounding XACML policy instances themselves, confidentiality-protected channels for


29422943

2944294529462947294829492950

2951

29522953295429552956295729582959

2960

29612962296329642965

29662967

296829692970

29712972

297329742975

29762977

2978

297929802981298229832984

85

the request/response protocol messages, protection of subject attributes in storage and in transit, and so on.

Selection and use of privacy mechanisms appropriate for a given environment are outside the scope of XACML. The decision regarding whether, how and when to deploy such mechanisms is left to the implementers associated with the environment.

10.9. Operational ConsiderationsCertain operational considerations will help reduce the risk of attacks or inadvertent misconfiguration of the system, leading to unintended behavior.

10.10. Resource MatchingIt is vital that the matching algorithm used to identify applicable policy based on the resource be functionally equivalent to the one used in dispatching the actual request within the application controlling the protected resource. This applies particularly in the case where the policy result of “NotApplicable” is treated as equivalent to “Permit” as is common in many Web servers. This situation does not usually occur when the PEP intercepts the request at the point of execution, but is frequently an issue if the PEP is implemented as a proxy or filter by different developers than the resource server.

A common example of this is a Web Server. Commercial http responders permit a variety of syntaxes to be treated equivalently. The “%” can be used to represent characters by hex value. In the URL path “/../” provides multiple ways of specifying the same value. Multiple character sets may be permitted and in some cases, the same printed character can be represented by different binary values. If the policy target matching algorithm considers two resource strings to be different, and the underlying Web server considers them to be the same, this may allow unintended access.

The usual solution to this problem is to put the request in a canonical form before matching. There may be practical difficulties with this strategy if the transformations are not completely documented or subject to change without notice from one version to the next. It is important to be aware of this issue and perform careful checking of marginal cases.

10.11. Negative PoliciesA negative policy is one that is based on some predicate not being "True". Because negative policies can lead to security risks, some authorities recommend that they NOT be used. However, negative policies can be extremely useful in certain cases, so XACML has chosen to permit them. It is recommended that they be used with care and avoided if possible.

A common situation for negative policies is to exclude an individual or subgroup from access allowed to a large group that includes them. For example, we might want to let all Vice Presidents see the unpublished financial data, except for Joe, who is only a Ceremonial Vice President and can be indiscreet in his communications. If we have complete control of the administration of subject attributes, a superior approach would be to define “Vice President” and “Ceremonial Vice President” as distinct groups and define policies appropriately. However, in some environments this approach may not be feasible. (It is worth noting in passing that, generally speaking, referring to individuals in policies does not scale well. Generally, shared attributes are preferred.)

Negative policies produce security risks in two common cases. They are: when information is suppressed and when the base universe changes. An example of suppressed information would be if we have a policy that access should be allowed, unless the entity is a credit risk. If it is possible that the attribute of being a credit risk may be unknown to the PDP for some reason,


29852986

298729882989

2990

29912992

2993

2994299529962997299829993000

3001300230033004300530063007

3008300930103011

3012

3013301430153016

30173018301930203021302230233024

3025302630273028

86

inappropriate access may be allowed. In some environments, the subject may be able to suppress the publication of attributes by the application of privacy controls, or the server or repository that contains the information may be unavailable for accidental or intentional reasons.

An example where the universe changes is a situation in which there is a policy that everyone in the engineering department can change code, except for secretaries. Suppose the department is merged with another engineering department and the intent is to maintain the same policy. However, the new department also has individuals identified as administrative assistants, who ought to be treated in the same way as secretaries. Unless the policy is altered, they will inappropriately be given access. Problems of this type are easy to avoid when one individual administers all policies, but when administration is distributed, as XACML permits, this type of situation must be explicitly guarded against.

10.12. XACML Threat ModelThe general Internet threat model described in the IETF guidelines for security considerations [ref.] is the basis for the XACML threat model. We assume here that the attacker has complete control over the communications channel.

Additionally, a legitimate user in a transaction may attempt to use information from a former transaction maliciously in subsequent transaction. It is further assumed that the use of rules and policies is only as good as the security of the system generating such assertions. Thus it is incumbent on the relying party to establish trust in the issuing parties. Such trust establishment is out of scope of this specification.

The data that is transmitted between the various entities in the XACML system are susceptible to a number of threats by malicious third parties. These entities of the XACML are the PIP and the persistent store. The threats also include the PEP and the PDP as well as the database containing the rules of the XACML system. While some of these entities are not strictly in scope for this specification, their compromise could compromise the authorization decision. An additional consideration when applying the various threats is that not all data is sensitive and subject to compromise by all the threats. It is up to the implementers of a specific XACML system to determine when a threat is important to their system.

It should be noted that there are other participants in a distributed system beside the XACML related entities, such as a compromised domain-name system (DNS), a compromised operating system, etc. that are out of scope for this discussion of threat models.

The following sections detail specific threats that could compromise an XACML system.

10.12.1 EavesdroppingXACML does not have any requirements for confidentiality between the various entities. Therefore, a malicious third party could observe the messages in transit. In certain situations disclosure of this information is very undesirable. Disclosure of attributes or the type of requests that a subject makes is considered a breach of privacy in many situations. In the commercial sphere there are instances where the disclosure of privacy data can range from embarrassing to the corporation responsible for the data to imprisonment and large fines in certain cases of medical or financial data. Patterns of requests could constitute a leak of information that could be useful in determining information that could help compromise the system.

The solution to situations where the possibility of undesirable disclosure of data is to use a technology that protects the message in transit, such as SSL, or to encrypt sensitive parts of the message using, for example, the encryption specification from the W3C. Using a point-to-point scheme like SSL may lead to other vulnerabilities when one of the recipients of a particular point-to-point hop is compromised.


302930303031

30323033303430353036303730383039

3040

304130423043

30443045304630473048

30493050305130523053305430553056

305730583059

3060

3061

30623063306430653066306730683069

30703071307230733074

87

10.12.2 ReplayThe primary problem associated with replay is the potential for denial of service attack. Also use of a stale message, say a rule, could cause a decision opposite to that which would otherwise be reached by a PDP.

The best solution to this type of attack is to prevent the capture of the message. This can be accomplished by using the transport protection as in the eavesdropping case. Note that encryption of the message will not help in a replay attack since the message is just used and does not have to be understood. Of course, hiding the contents of the message makes its use somewhat more difficult, since it will not be apparent to the attacker that this particular message would cause a problem, if that was their intent, rather than just denial of service. Compromise of any of the XACML entities, as described below, in the flow of data to the PDP and PEP could result in the capture of messages for replay.

10.12.3 Message InsertionMessage insertion used for other than replay means that the attacker would have to compose an XACML message. If the attacker has the ability to eavesdrop they could determine enough of the details of the messages being exchanged to construct their own message. In addition to constructing a message, either a request or a response, the attacker must have the ability to act as a one of the entities in the XACML system to successfully insert the message.

By inserting a request message the attacker could obtain sensitive information, or by inserting a false response the attacker could obtain access to sensitive resources to which they should not be permitted access.

The solution to a message insertion attack is to first defeat eavesdropping, as above, and to use mutual authentication between the entities in an XACML system. It should be noted that just using SSL mutual authentication is not sufficient. This only proves that the subject in the X.509 certificate is who the certificate says they are. In order to be effective the system must assure that the named entity is authorized to carry out the activity.

10.12.4 Message DeletionBy deleting well-chosen messages, e.g. certain rules in a policy, an attacker could change the authorization decision. In order to delete a message an attacker would have to have access to the message flow and understand the messages. Protecting the confidentiality of the messages as described above could defeat this attack.

10.12.5 Message ModificationIf an attacker can intercept a message and change its contents they could change an authorization decision. In order to accomplish this, the attacker would have to either obtain the message in transit or compromise one of the entities in an XACML data flow. Compromise of an intermediary can be prevented by mutual authentication. Both transport confidentiality and encryption can defeat the attack on the message in transit. Digitally signing the message will prevent modification of the message provided verification of the signature is carried out by the recipient.

10.12.6 Man-in-the-MiddleA Man-in-the-Middle attack is accomplished by intercepting the message flow and sending their own messages in one or both directions. Thus the man-in-the-middle could use any of the attacks described above once they establish themselves in the message flow. They could modify, delete, replay, eavesdrop or replay messages. Mutual authentication of the XACML entities would defeat


3075

307630773078

30793080308130823083308430853086

3087

30883089309030913092

309330943095

30963097309830993100

31013102310331043105

31063107310831093110311131123113

31143115311631173118

88

the Man-in-the-Middle attack. As discussed above, in order to be effective the system must assure that the named entity in the mutual authentication is authorized to carry out the activity.

11. Security and privacy (non-normative)This section identifies possible security and privacy vulnerabilities that should be considered when implementing an XACML-based system. This section is strictly informative. It has been left to the implementers to assess whether these vulnerabilities apply to their environment and to select the appropriate safeguards.

11.1. Authentication Authentication here means the ability of one party in a transaction to determine the identity of the other party in the transaction. Authentication may be in one direction, or it may be bilateral1.

Given the sensitive nature of access-control systems, it is important for a PEP to authenticate the identity of the PDP to which it sends decision requests. Otherwise, there is a risk that another process could provide false or invalid authorization decisions and compromise security of the access-control system.

It is equally important for a PDP to authenticate the identity of its clients and assess the level of trust to determine what, if any, sensitive data should be passed. One should keep in mind that even simple permit or deny responses could be exploited if someone was allowed to make unlimited requests to a PDP.

Many different techniques may be used to provide this authentication, such as co-located code, a private network, a VPN, or digital signatures. Authentication may also be done as part of the communication protocol used to exchange the contexts. In this case, the authentication may be performed at the message level or at the session level.

11.2. Confidentiality Confidentiality means that the contents of a message can be read only by the desired recipients and not by anyone else who encounters the message while it is in transit2. There are two areas in which confidentiality should be considered: one is confidentiality during transmission; the other is confidentiality within a <policyStatement>.


31193120

3121

3122312331243125

3126

31273128

3129313031313132

3133313431353136

3137313831393140

3141

3142314331443145

89

11.2.1Communication Confidentiality

11.2.2 All data within an access-control system should be treated as confidential. This includes the <policyStatement>, the XACML requests and responses, and any external data that may be referenced as part of the decision-making process. If someone is able to eavesdrop on the communication they may be able to understand under what circumstances access will be granted, which may allow them to impersonate a valid request.

11.2.3 Any security concerns or requirements related to transmitting or exchanging XACML <policyStatement> elements are outside the scope of the XACML standard. While it is often important to ensure that the integrity and confidentiality of <policyStatement> elements is maintained when they are exchanged between two parties, it is left to the implementers to determine the appropriate mechanisms for their environment.

11.2.4Statement Level Confidentiality

11.2.5 In some cases, an implementation may want to encrypt only parts of an XACML policy. For instance, a PRP only needs access to the target elements in order to find the appropriate rules. The other elements could be encrypted while they are stored in a repository.

11.2.6 The XML Encryption Syntax and Processing standard from W3C can be used to encrypt all or parts of an XML document. This standard is recommend for use with XACML.

11.2.7 It should go without saying that if a repository is used to facilitate the communication of cleartext (i.e., unencrypted) policy between the PAP and the PRP or between the PDP and the PIP, then a secure repository should be used to store this sensitive data.

[11.2.8] Policy Integrity


3146

3147314831493150315131523153

3154315531563157315831593160

3161

3162316331643165

316631673168

3169317031713172

3173

90

11.2.8[11.2.9] The XACML policy, used by the PDP to evaluate the request contexts, is the heart of the system. There are two aspects in maintaining the integrity of the policy. One is to ensure that <policyStatement> elements have not been altered since they were originally written or generated by the PAP. The other is to ensure that <policyStatement> elements have not been inserted or deleted from the set of policies.

11.2.9[11.2.10] In the many cases, this can be achieved by ensuring the integrity of the systems and implementing session-level techniques to secure the communication between parties. The selection of the appropriate techniques has been left to the implementers.

11.2.10[11.2.11] However, when policy is distributed between organizations to be acted on at a later time, or when the policy travels with data, it would be useful to have a digital signature of the policy included with the policy statements. In these cases, the XML Signature Syntax and Processing standard from W3C is recommended to be used with this standard. See section 8.3 [???] for examples of using XML digital signatures with XACML.

11.2.11[11.2.12] Digital signatures SHOULD only be used to ensure the integrity of the statements. Digital signatures SHOULD NOT be use as a method of selecting or evaluating policy. The PDP SHOULD NOT request a rule based on who signed the rule or whether or not it had been signed (as such a basis for selection would, itself, be a matter of policy).

11.2.12[11.2.13] Elements included by reference

11.2.13[11.2.14] There is a risk that references and extensions contained within a <policystatement> may have been altered since the policy was originally created, thereby changing the intent of the <policystatement>. For instance, if a <policyStatement> were to include a rule by reference, then there is no guarantee that the rule has not been changed between the time that the policy was written and the time that it is being evaluated.


3174317531763177317831793180

3181318231833184

3185318631873188318931903191

319231933194319531963197

3198

3199320032013202320332043205

91

11.2.14[11.2.15] A <ruleDigest> element can be used to uniquely identify a rule. The <ruleDigest> element contains a digest of the original rule. If the rule changed, then the rule digest would also change. Therefore, if the <policyStatement> is signed or integrity-protected in some other way (so that the <ruleDigest> cannot be altered without detection), the PDP can be certain that the referenced rules have not changed since the policy was created.

11.2.15[11.2.16] Alternatively, a digital signature of the source item could be included with the reference. [I don’t see this in the schema. Can we do this?] This technique will also allow the PDP to ensure that a rule or extension has not been altered (although integrity protection is still required on the policy itself; otherwise, the included signatures may be removed or replaced).

[11.2.17] Trust Model

11.2.16[11.2.18] Discussions of authentication, integrity, and confidentiality mechanisms necessarily assume an underlying trust model: how can one entity come to believe that a given key is uniquely associated with a specific, identified entity so that the key can be used to encrypt data for that entity or verify signatures (or other integrity structures) from that entity? Many different types of trust model exist, including strict hierarchies, distributed authorities, the Web, the bridge, and so on.

11.2.17[11.2.19] All considerations with respect to choosing and establishing a suitable trust model for a given environment are outside the scope of XACML. Suffice it to say, however, that a trust model MUST be in place in order for any of the security mechanisms described in this section to be applied. Secure access control is not possible in any environment until a trust model appropriate for that environment has been established and implemented.

11.2.18[11.2.20] Privacy


3206320732083209321032113212

321332143215321632173218

3219

32203221322232233224322532263227

3228322932303231323232333234

3235

92

11.2.19[11.2.21] It is important to be aware that any transactions that occur with respect to access control may reveal private information about the participants. For example, if an XACML policy states that certain data may only be read by individuals with “Gold Card Member” status, then any transaction in which an entity is given access to that data leaks information to external observers about that entity’s status. Privacy considerations may therefore lead to encryption or access control policies surrounding XACML policy instances themselves, confidentiality-protected channels for the request/response protocol messages, protection of user attributes in storage and in transit, and so on.

11.2.20[11.2.22] Selection and use of privacy mechanisms appropriate for a given environment are outside the scope of XACML. The decision regarding whether, how, and when to deploy such mechanisms is left to the implementers associated with the environment.

11.2.21[11.2.23] Footnotes

11.2.22[11.2.24] 1 - Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) section 4.1

11.2.23[11.2.25] 2 - Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) section 4.2

11.2.24[11.2.26] Conformance (normative)

11.3. IntroductionConformance claims MAY be made by either one of two components in the XACML model:

1. An implementation of a policy administration pointsPAP that produces <Ppolicy> statements elements that conform with the XACML schema; and

2. An implementation of a policy decision pointPDP that produces dauthorization decisions in response to a request context on the basis of XACML <Ppolicy> statements elements that conform with the XACML schema.

In the current version of the specification, implementations of a policy retrieval point that produce policy statements that conform with the XACML schema by combining XACML applicable policies are treated in the same way as policy administration points, from the point of view of conformance.

Policy administration pointsPAPs MAY claim conformance with the XACML specification provided merely that they produce schema-compliant policy statements.

Policy decision pointsPDPs MAY claim conformance with the XACML specification provided that they correctly execute the XACML conformance test suite provided at:


32363237323832393240324132423243324432453246

3247324832493250

3251

32523253

32543255

3256

3257

3258

32593260

326132623263

326432653266

32673268

32693270

93

http://www.oasis-open.org/ …

11.4. XACML tTest sSuiteAn implementation that "successfully uses" the XACML specification MUST pass the test suite. The test suite comprises three directories:

Request context

Policy

Response context

The input context directory contains a set of text/xml/ xacmlContext:RequestType files that are valid XACML input contexts.

The policy directory contains precisely one XACML policy file whose target is appropriate for each of the input contexts.

The output context directory contains a set of text/xml/ xacmlContext:ResponseType files containing the output contexts that correspond to the input contexts in the input context directory.

A conformant XACML PDP implementation shall create an output context in response to each and every input context. The output contexts are linked to the corresponding input contexts by the request context ID attribute. [There’s no such thing at the moment.]

XACML implementations that target a specific application domain (e.g., SAML or J2SE) may use a tool or process that is not an integral part of the XACML implementation to convert between the XACML contexts and its private data representation.

Disclaimer: Implementeors SHALL NOT consider the test cases provided in the XACML conformance test suite as providing 100% test coverage. OASIS does not represent that a conformant implementation will operate correctly in all respects nor that it is fit for its purpose.

11.5. XACML schema elements, identifiers and algorithmsConformance tables

This section lists those portions of the specification that MUST be included in an implementation of a PDP that claims to conform with XACML v1.0.

Note: "M" means mandatory-to-implement

11.5.1Schema eElementsxacml:Policy AbstractDefaults ?xacml:Policy Action Mxacml:Policy ActionAttributeDesignator Mxacml:Policy ActionMatch Mxacml:Policy Actions Mxacml:Policy AnyAction Mxacml:Policy AnyResource Mxacml:Policy AnySubject Mxacml:Policy Apply Mxacml:Policy AttributeAssignmentxacml:Policy AttributeSelectorxacml:Policy AttributeValue M


3271

3272

32733274

3275

3276

3277

32783279

32803281

32823283

328432853286

328732883289

329032913292

32933294

32953296

3297

3298

94

http://www.oasis-open.org/

xacml:Policy Condition Mxacml:Policy Description Mxacml:Policy EnvironmentAttributeDesignator Mxacml:Policy Obligationxacml:Policy Obligationsxacml:Policy Policy Mxacml:Policy PolicyDefaults ?xacml:Policy PolicyId Mxacml:Policy PolicySet Mxacml:Policy PolicySetDefaults ?xacml:Policy PolicySetId Mxacml:Policy Resource Mxacml:Policy ResourceAttributeDesignator Mxacml:Policy ResourceMatch Mxacml:Policy Resources Mxacml:Policy Rule Mxacml:Policy Subject Mxacml:Policy SubjectAttributeDesignator Mxacml:Policy SubjectAttributeDesignatorWhere Mxacml:Policy SubjectMatch Mxacml:Policy Subjects Mxacml:Policy Target Mxacml:Policy XPathVersionxacml:Context Action Mxacml:Context Attribute Mxacml:Context AttributeValue Mxacml:Context Decision Mxacml:Context Environment Mxacml:Context Obligationsxacml:Context Request Mxacml:Context Resource Mxacml:Context ResourceContentxacml:Context Response Mxacml:Context Result Mxacml:Context Statusxacml:Context StatusCodexacml:Context StatusDetailxacml:Context StatusMessagexacml:Context Subject M

? xacml AbstractDefaults (abstract)M xacml ActionM xacml ActionAttributeDesignatorM xacml ActionMatchM xacml ActionsM xacml AnyActionM xacml AnyResourceM xacml AnySubjectM xacml Apply xacml AttributeAssignment xacml AttributeSelectorM xacml AttributeValueM xacml ConditionM xacml Description


329933003301330233033304330533063307330833093310331133123313

95

M xacml EnvironmentAttributeDesignator xacml Obligation xacml ObligationsM xacml Policy? xacml PolicyDefaultsM xacml PolicyIdM xacml PolicySet? xacml PolicySetDefaultsM xacml PolicySetIdM xacml ResourceM xacml ResourceAttributeDesignatorM xacml ResourceMatchM xacml ResourcesM xacml RuleM xacml SubjectM xacml SubjectAttributeDesignatorM xacml SubjectAttributeDesignatorWhereM xacml SubjectMatchM xacml SubjectsM xacml Target xacml XPathVersionM xacml-context ActionM xacml-context AttributeM xacml-context AttributeValueM xacml-context DecisionM xacml-context Environment xacml-context ObligationsM xacml-context RequestM xacml-context Resource xacml-context ResourceContentM xacml-context ResponseM xacml-context Result xacml-context Status xacml-context StatusCode xacml-context StatusDetail xacml-context StatusMessageM xacml-context Subject

11.5.2AlgorithmsThe implementation MUST include the rule- and policy-combining algorithms marked "M".

Deny-Overrides M

First-Applicable M

Permit-Overrides M

M Deny-OverridesM First-ApplicableM Permit-OverridesIdentifiers

The implementation MUST properly process those identifiers marked with an "M".urn:oasis:names:tc:xacml:1.0 Murn:oasis:names:tc:xacml:1.0:auth-locality:dns-name M


3314331533163317331833193320332133223323332433253326332733283329333033313332333333343335333633373338333933403341334233433344334533463347334833493350

3351

3352

33533354335533563357

3358

96

urn:oasis:names:tc:xacml:1.0:auth-locality:ip-addressurn:oasis:names:tc:xacml:1.0:conformance-test Murn:oasis:names:tc:xacml:1.0:context Murn:oasis:names:tc:xacml:1.0:datatype:numeric Murn:oasis:names:tc:xacml:1.0:datatype:rfc822name Murn:oasis:names:tc:xacml:1.0:datatype:ufs-path Murn:oasis:names:tc:xacml:1.0:datatype:x500name Murn:oasis:names:tc:xacml:1.0:environment:current-time Murn:oasis:names:tc:xacml:1.0:example:actionurn:oasis:names:tc:xacml:1.0:example:action:readurn:oasis:names:tc:xacml:1.0:example:action:xml-acurn:oasis:names:tc:xacml:1.0:example:attributeurn:oasis:names:tc:xacml:1.0:example:attribute:groupurn:oasis:names:tc:xacml:1.0:example:attribute:roleurn:oasis:names:tc:xacml:1.0:function Murn:oasis:names:tc:xacml:1.0:policy Murn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:deny-overrides

M

urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:first-applicable

M

urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:permit-overrides

M

urn:oasis:names:tc:xacml:1.0:resource:resource-location Murn:oasis:names:tc:xacml:1.0:resource:resource-uri Murn:oasis:names:tc:xacml:1.0:resource:simple-file-name Murn:oasis:names:tc:xacml:1.0:resource:xpathurn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides

M

urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable

M

urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides

M

urn:oasis:names:tc:xacml:1.0:status:missing-attributeurn:oasis:names:tc:xacml:1.0:status:okurn:oasis:names:tc:xacml:1.0:status:processing-errorurn:oasis:names:tc:xacml:1.0:status:syntax-errorurn:oasis:names:tc:xacml:1.0:subject:authentication-method Murn:oasis:names:tc:xacml:1.0:subject:authentication-time Murn:oasis:names:tc:xacml:1.0:subject:key-info Murn:oasis:names:tc:xacml:1.0:subject:request-time Murn:oasis:names:tc:xacml:1.0:subject:session-start-time Murn:oasis:names:tc:xacml:1.0:subject:subject-category Murn:oasis:names:tc:xacml:1.0:subject:subject-id Murn:oasis:names:tc:xacml:1.0:subject:subject-id-qualifier Murn:oasis:names:tc:xacml:1.0:subject-category:access-subject

M

urn:oasis:names:tc:xacml:1.0:subject-category:codebaseurn:oasis:names:tc:xacml:1.0:subject-category:intermediary-subjecturn:oasis:names:tc:xacml:1.0:subject-category:recipient-subjecturn:oasis:names:tc:xacml:1.0:subject-category:requesting-machinexs:Gregorian Mxs:dayTimeDuration


xs:yearMonthDuration

M urn:oasis:names:tc:xacml:1.0M urn:oasis:names:tc:xacml:1.0:auth-locality:dns-name urn:oasis:names:tc:xacml:1.0:auth-locality:ip-addressM urn:oasis:names:tc:xacml:1.0:conformance-testM urn:oasis:names:tc:xacml:1.0:contextM urn:oasis:names:tc:xacml:1.0:datatype:numericM urn:oasis:names:tc:xacml:1.0:datatype:rfc822nameM urn:oasis:names:tc:xacml:1.0:datatype:ufs-pathM urn:oasis:names:tc:xacml:1.0:datatype:x500nameM urn:oasis:names:tc:xacml:1.0:environment:current-time urn:oasis:names:tc:xacml:1.0:example:action urn:oasis:names:tc:xacml:1.0:example:action:read urn:oasis:names:tc:xacml:1.0:example:action:xml-ac urn:oasis:names:tc:xacml:1.0:example:attribute urn:oasis:names:tc:xacml:1.0:example:attribute:group urn:oasis:names:tc:xacml:1.0:example:attribute:roleM urn:oasis:names:tc:xacml:1.0:functionM urn:oasis:names:tc:xacml:1.0:policyM urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:deny-overridesM urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:first-applicableM urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:permit-overridesM urn:oasis:names:tc:xacml:1.0:resource:resource-locationM urn:oasis:names:tc:xacml:1.0:resource:resource-uriM urn:oasis:names:tc:xacml:1.0:resource:simple-file-name urn:oasis:names:tc:xacml:1.0:resource:xpathM urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overridesM urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicableM urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides urn:oasis:names:tc:xacml:1.0:status:missing-attribute urn:oasis:names:tc:xacml:1.0:status:ok urn:oasis:names:tc:xacml:1.0:status:processing-error urn:oasis:names:tc:xacml:1.0:status:syntax-errorM urn:oasis:names:tc:xacml:1.0:subject:authentication-methodM urn:oasis:names:tc:xacml:1.0:subject:authentication-timeM urn:oasis:names:tc:xacml:1.0:subject:key-infoM urn:oasis:names:tc:xacml:1.0:subject:request-timeM urn:oasis:names:tc:xacml:1.0:subject:session-start-timeM urn:oasis:names:tc:xacml:1.0:subject:subject-categoryM urn:oasis:names:tc:xacml:1.0:subject:subject-idM urn:oasis:names:tc:xacml:1.0:subject:subject-id-qualifierM urn:oasis:names:tc:xacml:1.0:subject-category:access-subject urn:oasis:names:tc:xacml:1.0:subject-category:codebase urn:oasis:names:tc:xacml:1.0:subject-category:intermediary-subject urn:oasis:names:tc:xacml:1.0:subject-category:recipient-subject urn:oasis:names:tc:xacml:1.0:subject-category:requesting-machineM xs:Gregorian xs:dayTimeDuration xs:yearMonthDuration

11.5.3Function identifierThe implementation MUST properly process those functions marked with an "M".


335933603361336233633364336533663367336833693370337133723373337433753376337733783379338033813382338333843385338633873388338933903391339233933394339533963397339833993400340134023403340434053406340734083409

3410

3411

98

function:integer-add M

function:decimal-add M

function:add-yearMonthDuration-to-date


function:add-dayTimeDuration-to-time

function:add-yearMonthDuration-to dateTime

function:add-dayTimeDuration-to-dateTime

function:add-yearMonthDurations

function:add-dayTimeDurations

function:integer-subtract M

function:decimal-subtract M

function:date-subtract

function:subtract-yearMonthDuration-from-date

function:subtract-dayTimeDuration-from-date

function:time-subtract

function:subtract-dayTimeDuration-from-time

function:datetime-subtract

function:subtract-yearMonthDuration-from-dateTime

function:subtract-dayTimeDuration-from-dateTime

function:subtract-yearMonthDurations

function:subtract-dayTimeDurations

function:integer-multiply M

function:decimal-multiply M

function:multiply-yearMonthDurations

function:multiply-dayTimeDurations

function:integer-divide M

function:decimal-divide M

function:divide-yearMonthDurations

function:divide-dayTimeDurations

function:integer-mod M

function:decimal-mod M

function:round M


function:floor M

function:abs M

function:integer M

function:decimal M

function:integer-equal M

function:decimal-equal M

function:boolean-equal M

function:string-equal M

function:rfc822Name-equal M

function:x500Name-equal M

function:date-equal M

function:time-equal M

function:datetime-equal M

function:yearMonthDuration-equal

function:dayTimeDuration-equal

function:gregorian-equal M

function:hex-binary-equal M

function:base64-binary-equal M

function:anyURI-equal M

function:QName-equal M

function:NOTATION-equal M

function:numeric-not-equal

function:boolean-not-equal

function:string-not-equal

function:date-not-equal

function:time-not-equal

function:datetime-not-equal

function:yearMonthDuration-not-equal

function:dayTimeDuration-not-equal

function:gregorian-not-equal

function:hex-binary-not-equal

function:base64-binary-not-equal


function:anyURI-not-equal

function:QName-not-equal

function:NOTATION-not-equal

function:integer-greater-than M

function:decimal-greater-than M

function:string-greater-than M

function:date-greater-than M

function:time-greater-than M

function:datetime-greater-than M

function:yearMonthDuration-greater-than

function:dayTimeDuration-greater-than

function:integer-less-than

function:decimal-less-than

function:string-less-than

function:date-less-than

function:time-less-than

function:datetime-less-than

function:yearMonthDuration-less-than

function:dayTimeDuration-less-than

function:integer-greater-than-or-equal M

function:decimal-greater-than-or-equal M

function:string-greater-than-or-equal M

function:date-greater-than-or-equal M

function:time-greater-than-or-equal M

function:datetime-greater-than-or-equal M

function:yearMonthDuration-greater-than-or-equal

function:dayTimeDuration-greater-than-or-equal

function:integer-less-than-or-equal

function:decimal-less-than-or-equal

function:numeric-less-than-or-equal

function:date-less-than-or-equal

function:time-less-than-or-equal


function:datetime-less-than-or-equal

function:yearMonthDuration-less-than-or-equal

function:dayTimeDuration-less-than-or-equal

function:string-match M

function:rfc822Name-match M

function:x500Name-match M

function:and M

function:ordered-and M

function:or M

function:ordered-or M

function:n-of M

function:not M

function:present M

X-intersection M

X-union M

X-member-of M

X-first M

X-rest M

x-length m

Where "X" can be any supported data type.

References

[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997

[RegEx] [SAML] Security Assertion Markup Language available from http://www.oasis-

open.org/committees/security/#documents [XMLSig] D. Eastlake et al., XML-Signature Syntax and Processing,

http://www.w3.org/TR/xmldsig-core/, World Wide Web Consortium.[XMLSig-XSD] XML Signature Schema available from http://www.w3.org/TR/2000/CR-

xmldsig-core-20001031/xmldsig-core-schema.xsd. [Hinton94] Hinton, H, M, Lee,, E, S, The Compatibility of Policies, Proceedings 2nd

ACM Conference on Computer and Communications Security, Nov 1994, Fairfax, Virginia, USA.

[LDAP] RFC2798, Definition of the inetOrgPerson, M. Smith, April 2000 http://www.ietf.org/rfc/rfc2798.txt

[MathML] Mathematical Markup Language (MathML), Version 2.0, W3C Recommendation, 21 February 2001. Available at: http://www.w3.org/TR/MathML2/


3412

3413

34143415341634173418341934203421342234233424342534263427342834293430

102

http://www.ietf.org/rfc/rfc2798.txt

http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/xmldsig-core-schema.xsd


http://www.w3.org/TR/xmldsig-core/


[Perritt93] Perritt, H. Knowbots, Permissions Headers and Contract Law, Conference on Technological Strategies for Protecting Intellectual Property in the Networked Multimedia Environment, April 1993. Available at: http://www.ifla.org/documents/infopol/copyright/perh2.txt

[RBAC] Role-Based Access Controls, David Ferraiolo and Richard Kuhn, 15th National Computer Security Conference, 1992. Available at: http://csrc.nist.gov/rbac

[RegEx] XML Schema Part 0: Primer, W3C Recommendation, 2 May 2001, Appendix D. Available at: http://www.w3.org/TR/xmlschema-0/

[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997

[SAML] Security Assertion Markup Language available from http://www.oasis-open.org/committees/security/#documents

[Sloman94] Sloman, M. Policy Driven Management for Distributed Systems. Journal of Network and Systems Management, Volume 2, part 4. Plenum Press. 1994.

[XMLSig] D. Eastlake et al., XML-Signature Syntax and Processing, http://www.w3.org/TR/xmldsig-core/, World Wide Web Consortium.

[XMLSig-XSD] XML Signature Schema available from http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/xmldsig-core-schema.xsd.

[XPath] XML Path Language (XPath), Version 1.0, W3C Recommendation 16 November 1999. Available at: http://www.w3.org/TR/xpath

[XSLT] XSL Transformations (XSLT) Version 1.0, W3C Recommendation 16 November 1999. Available at: http://www.w3.org/TR/xslt


3431343234333434343534363437

34383439

34403441

34423443

34443445344634473448344934503451345234533454

103



http://www.w3.org/TR/xmldsig-core/


http://www.ifla.org/documents/infopol/copyright/perh2.txt

Appendix A. Function names and legal type combinations

A.1. FunctionsThe table in this section lists the legal combinations of datatypes for the various functions. For each function name, the table indicates the valid combination of datatypes and the datatype of the result.

Function name Return type First argument Second argument Third and subsequent

arguments

Can be used

in <Match>

Can be used

in <Condition>

string-equal single<xs:boolean> single<xs:string> single<xs:string> yes yes

boolean-equal single<xs:boolean> single<xs:boolean> single<xs:boolean> yes yes

integer-equal single<xs:boolean> single<xs:integer> single<xs:integer> yes yes

decimal-equal single<xs:boolean> single<xs:decimal> single<xs:decimal> yes yes

date-equal single<xs:boolean> single<xs:date> single<xs:date> yes yes

time-equal single<xs:boolean> single<xs_time> single<xs_time> yes yes

datetime-equal single<xs:boolean> single<xs:dateTime> single<xs:dateTime>

yes yes

anyURI-equal single<xs:boolean> single<xs:anyURI> single<xs:anyURI> yes yes

Qname-equal single<xs:boolean> single<xs:Qname> single<xs:Qname> yes yes

x500Name-equal single<xs:boolean> single<x500Name> single<x500Name> yes yes

rfc822Name-equal

single<xs:boolean> single<rfc822Name> single<rfc822Name>

yes yes

NOTATION-equal

single<xs:boolean> single<xs:NOTATION>

single<xs:NOTATION>

yes yes

gregorian-equal single<xs:boolean> single<xs:gregorian> single<rfc822Name>

yes yes

hex-binary-equal single<xs:boolean> single<xs:hex-binary> single<xs:hex-binary>

yes yes

base64-equal single<xs:boolean> single<xs:base64> single<xs:base64> yes yes

integer-add single<xs:integer> single<xs:integer> single<xs:integer> single<xs:integer>

no no

decimal-add single<xs:decimal> single<xs:decimal> single<xs:decimal> single<xs:decimal>

no no

integer-subtract single<xs:integer> single<xs:integer> single<xs:integer> no no

decimal-subtract single<xs:decimal> single<xs:decimal> single<xs:decimal> no no

integer-multiply single<xs:integer> single<xs:integer> single<xs:integer> no no

decimal-multiply single<xs:decimal> single<xs:decimal> single<xs:decimal> no no

integer-divide single<xs:integer> single<xs:integer> single<xs:integer> no no

decimal-divide single<xs:decimal> single<xs:decimal> single<xs:decimal> no no


3455

3456

3457

34583459

104

integer-mod single<xs:integer> single<xs:integer> single<xs:integer> no no

decimal-mod single<xs:decimal> single<xs:decimal> single<xs:decimal> no no

round ne_sequence<xs:decimal>

ne_sequence<xs:decimal>

no no

floor ne_sequence<xs:decimal>


no no

abs ne_sequence<xs:decimal>


no no

decimal-to-integer

ne_sequence<xs:integer>


no no

integer-to-decimal


ne_sequence<xs:integer>

no no

ordered-or single<xs:boolean> single<xs:boolean> single<xs:boolean> single<xs:boolean>

no yes

or single<xs:boolean> single<xs:boolean> single<xs:boolean> single<xs:boolean>

no yes

ordered-and single<xs:boolean> single<xs:boolean> single<xs:boolean> single<xs:boolean>

no yes

and single<xs:boolean> single<xs:boolean> single<xs:boolean> single<xs:boolean>

no yes

not single<xs:boolean> single<xs:boolean> single<xs:boolean> single<xs:boolean>

no yes

n-of single<xs:boolean> single<xs:integer> single<xs:boolean> single<xs:boolean>

no yes

integer-greater-then

single<xs:boolean> single<xs:integer> single<xs:integer> no yes

integer-greater-then-or-equal

single<xs:boolean> single<xs:integer> single<xs:integer> no yes

time-greater-then single<xs:boolean> single<xs:time> single<xs:time> no yes

time-greater-then-or-equal

single<xs:boolean> single<xs:time> single<xs:time> no yes

date-greater-then

single<xs:boolean> single<xs:date> single<xs:date> no yes

date-greater-then-or-equal

single<xs:boolean> single<xs:date> single<xs:date> no yes

datetime-greater-then

single<xs:boolean> single<xs:datetime> single<xs:datetime>

no yes

datetime-greater-then-or-equal

single<xs:boolean> single<xs:datetime> single<xs:datetime>

no yes

decimal-greater single<xs:boolean> single<xs:decimal> single<xs:decimal> no yes

decimal-greater-then-or-equal

single<xs:boolean> single<xs:decimal> single<xs:decimal> no yes

string-greater single<xs:boolean> single<xs:string> single<xs:string> no yes

string-greater-then-or-equal

single<xs:boolean> single<xs:string> single<xs:string> no yes

string-match single<xs:boolean> single<xs:string> single<xs:string> yes yes


x500Name-match

single<xs:boolean> single<x500Name> single<x500Name> yes yes

rfc822Name-match

single<xs:boolean> single<rfc822Name> single<rfc822Name>

yes yes

present single<xs:boolean> single<xs:anyURI> no yes

string-intesection set<xs:string> set<xs:string> set<xs:string> no no

boolean-intersection

set<xs:boolean> set<xs:boolean> set<xs:boolean> no no

integer-intersection

set<xs:integer> set<xs:integer> set<xs:integer> no no

decimal-intersection

set<xs:decimal> set<xs:decimal> set<xs:decimal> no no

date-intersection set<xs:date> set<xs:date> set<xs:date> no no

time-intersection set<xs_time> set<xs_time> set<xs_time> no no

dateTime-intersection

set<xs:dateTime> set<xs:dateTime> set<xs:dateTime> no no

anyURI-intersection

set<xs:anyURI> set<xs:anyURI> set<xs:anyURI> no no

Qname-intersection

set<xs:Qname> set<xs:Qname> set<xs:Qname> no no

x500Name-intersection

set<x500Name> set<x500Name> set<x500Name> no no

rfc822Name-intersection

set<rfc822Name> set<rfc822Name> set<rfc822Name> no no

NOTATION-intersection

set<xs:NOTATION> set<xs:NOTATION> set<xs:NOTATION>

no no

gregorian-intersection

set<xs:gregorian> set<xs:gregorian> set<rfc822Name> no no

hex-binary-intersection

set<xs:hex-binary> set<xs:hex-binary> set<xs:hex-binary> no no

base64-intersection

set<xs:base64> set<xs:base64> set<xs:base64> no no

date-union set<xs:date> set<xs:date> set<xs:date> no no

time-union set<xs_time> set<xs_time> set<xs_time> no no

dateTime-union set<xs:dateTime> set<xs:dateTime> set<xs:dateTime> no no

anyURI-union set<xs:anyURI> set<xs:anyURI> set<xs:anyURI> no no

Qname-union set<xs:Qname> set<xs:Qname> set<xs:Qname> no no

x500Name-union set<x500Name> set<x500Name> set<x500Name> no no

rfc822Name-union

set<rfc822Name> set<rfc822Name> set<rfc822Name> no no

NOTATION-union

set<xs:NOTATION> set<xs:NOTATION> set<xs:NOTATION>

yes yes

gregorian-union set<xs:gregorian> set<xs:gregorian> set<rfc822Name> yes yes

hex-binary-union set<xs:hex-binary> set<xs:hex-binary> set<xs:hex-binary> yes yes

base64-union set<xs:base64> set<xs:base64> set<xs:base64> yes yes


date-member-of single<xs:boolean> single<xs:date> set<xs:date> yes yes

time-member-of single<xs:boolean> single<xs_time> set<xs_time> yes yes

dateTime-member-of

single<xs:boolean> single<xs:dateTime> set<xs:dateTime> yes yes

anyURI-member-of

single<xs:boolean> single<xs:anyURI> set<xs:anyURI> yes yes

Qname-member-of

single<xs:boolean> single<xs:Qname> set<xs:Qname> yes yes

x500Name-member-of

single<xs:boolean> single<x500Name> set<x500Name> yes yes

rfc822Name-member-of

single<xs:boolean> single<rfc822Name> set<rfc822Name> yes yes

NOTATION-member-of

single<xs:boolean> single<xs:NOTATION>

set<xs:NOTATION>

yes yes

gregorian-member-of

single<xs:boolean> single<xs:gregorian> set<rfc822Name> yes yes

hex-binary-member-of

single<xs:boolean> single<xs:hex-binary> set<xs:hex-binary> yes yes

base64-member-of

single<xs:boolean> single<xs:base64> set<xs:base64> yes yes

date-first single<xs:date> ne_sequence<xs:date>

no no

time-first single<xs_time> ne_sequence<xs_time>

no no

dateTime-first single<xs:dateTime>

ne_sequence<xs:dateTime>

no no

anyURI-first single<xs:anyURI> ne_sequence<xs:anyURI>

no no

Qname-first single<xs:Qname> ne_sequence<xs:Qname>

no no

x500Name-first single<x500Name> ne_sequence<x500Name>

no no

rfc822Name-first single<rfc822Name>

ne_sequence<rfc822Name>

no no

NOTATION-first single<xs:NOTATION>

ne_sequence<xs:NOTATION>

no no

gregorian-first single<xs:gregorian>

ne_sequence<xs:gregorian>

no no

hex-binary-first single<xs:hex-binary>

ne_sequence<xs:hex-binary>

no no

base64-first single<xs:base64> ne_sequence<xs:base64>

no no

date-rest sequence<xs:date> ne_sequence<xs:date>

no no

time-rest sequence<xs_time> ne_sequence<xs_time>

no no

dateTime-rest sequence<xs:dateTime>

ne_sequence<xs:dateTime>

no no


anyURI-rest sequence<xs:anyURI>

ne_sequence<xs:anyURI>

no no

Qname-rest sequence<xs:Qname>

ne_sequence<xs:Qname>

no no

x500Name-rest sequence<x500Name>

ne_sequence<x500Name>

no no

rfc822Name-rest sequence<rfc822Name>

ne_sequence<rfc822Name>

no no

NOTATION-rest sequence<xs:NOTATION>

single<xs:NOTATION>

no no

gregorian-rest sequence<xs:gregorian>

single<xs:gregorian> no no

hex-binary-rest sequence<xs:hex-binary>

single<xs:hex-binary> no no

base64-rest sequence<xs:base64>

single<xs:base64> no no

date-length single<xs:integer> sequence<xs:date> no no

time-length single<xs:integer> sequence<xs_time> no no

dateTime-length single<xs:integer> sequence<xs:dateTime>

no no

anyURI-length single<xs:integer> sequence<xs:anyURI>

no no

Qname-length single<xs:integer> sequence<xs:Qname>

no no

x500Name-length

single<xs:integer> sequence<x500Name>

no no

rfc822Name-length

single<xs:integer> sequence<rfc822Name>

no no

NOTATION-length

single<xs:integer> sequence<xs:NOTATION>

no no

gregorian-length single<xs:integer> sequence<xs:gregorian>

no no

hex-binary-length

single<xs:integer> sequence<xs:hex-binary>

no no

base64-length single<xs:integer> sequence<xs:base64>

no no

Function Name Function DataType

First operand DataType

Remaining operands DataType

Operation

function:integer-add xs:integer xs:integer xs:integer A + B

function:decimal-add xs:decimal xs:decimal xs:decimal A + B


xs:date xs:date xs:yearMonthDuration A + B


3460

3461

108


xs:date xs:date xs:dayTimeDuration A + B

function:add-dayTimeDuration-to-time

xs:time xs:time xs:dayTimeDuration A + B

function:add-yearMonthDuration-to-dateTime

xs:dateTime xs:datetime xs:yearMonthDuration A + B

function:add-dayTimeDuration-to-dateTime

xs:dateTime xs:datetime xs:dayTimeDuration A + B

function:add-yearMonthDurationsxs:yearMonthDuration


xs:yearMonthDuration A + B

function:add-dayTimeDurations xs:dayTimeDuration

xs:dayTimeDuration

xs:dayTimeDuration A + B

function:integer-subtract xs:integer xs:integer xs:integer A - B

function:decimal-subtract xs:decimal xs:decimal xs:decimal A - B

function:date-subtract xs:dayTimeDuration

xs:date xs:date A - B (only two operands allowed)

function:subtract-yearMonthDuration-from-date

xs:date xs:date xs:yearMonthDuration A - B

function:subtract-dayTimeDuration-from-date

xs:date xs:date xs:dayTimeDuration A - B

function:time-subtract xs:dayTimeDuration

xs:time xs:time A - B (only two operands allowed)

function:subtract-dayTimeDuration-from-time

xs:time xs:time xs:dayTimeDuration A - B

function:datetime-subtract xs:dayTimeDuration

xs:datetime xs:datetime A - B (only two operands allowed)

function:subtract-yearMonthDuration-from-dateTime

xs:dateTime xs:datetime xs:yearMonthDuration A - B

function:subtract-dayTimeDuration-from-dateTime

xs:dateTime xs:datetime xs:dayTimeDuration A - B

function:subtract-yearMonthDurations



xs:yearMonthDuration A - B

function:subtract-dayTimeDurations

xs:dayTimeDuration

xs:dayTimeDuration

xs:dayTimeDuration A - B

function:integer-multiply xs:integer xs:integer xs:integer A * B


function:decimal-multiply xs:decimal xs:decimal xs:decimal A * B

function:multiply-yearMonthDurations



xs:decimal A * B

function:multiply-dayTimeDurations

xs:dayTimeDuration

xs:dayTimeDuration

xs:decimal A * B

function:integer-divide xs:integer xs:integer xs:integer A div B

function:decimal-divide xs:decimal xs:decimal xs:decimal A div B

function:divide-yearMonthDurations



xs:decimal A div B

function:divide-dayTimeDurationsxs:dayTimeDuration

xs:dayTimeDuration

xs:decimal A div B

function:integer-mod xs:integer xs:integer xs:integer A mod B

function:decimal-mod xs:decimal xs:decimal xs:decimal A mod B

function:round xs:integer xs:decimal

function:integer xs:integer xs:decimal

function:decimal xs:decimal xs:integer

function:integer-equal xs:boolean xs:integer xs:integer A eq B

function:decimal-equal xs:boolean xs:decimal xs:decimal A eq B

function:boolean-equal xs:boolean xs:boolean xs:boolean A eq B

function:string-equal xs:boolean xs:string xs:string A eq B

function:rfc822Name-equal xs:boolean Identifier:rfc822Name

Identifier:rfc822Name A eq B

function:x500Name-equal xs:boolean Identifier:x500Name

Identifier:x500Name A eq B

function:date-equal xs:boolean xs:date xs:date A eq B

function:time-equal xs:boolean xs:time xs:time A eq B

function:datetime-equal xs:boolean xs:dateTime xs:dateTime A eq B

function:yearMonthDuration-equal

xs:boolean xs:yearMonthDuration

xs:yearMonthDuration A eq B

function:dayTimeDuration-equal xs:boolean xs:dayTimeDuration

xs:dayTimeDuration A eq B

function:gregorian-equal xs:boolean Gregorian Gregorian A eq B

function:hex-binary-equal xs:boolean xs:hexBinary xs:hexBinary A eq B

function:base64-binary-equal xs:boolean xs:base64Binar xs:base64Binar A eq B


y y

function:anyURI-equal xs:boolean xs:anyURI xs:anyURI A eq B

function:QName-equal xs:boolean xs:QName xs:QName A eq B

function:NOTATION-equal xs:boolean xs:NOTATION xs:NOTATION A eq B

function:numeric-not-equal xs:boolean numeric numeric A ne B

function:boolean-not-equal xs:boolean xs:boolean xs:boolean A ne B

function:string-not-equal xs:boolean xs:string xs:string A ne B

function:date-not-equal xs:boolean xs:date xs:date A ne B

function:time-not-equal xs:boolean xs:time xs:time A ne B

function:datetime-not-equal xs:boolean xs:dateTime xs:dateTime A ne B

function:yearMonthDuration-not-equal


xs:yearMonthDuration A ne B

function:dayTimeDuration-not-equal

xs:boolean xs:dayTimeDuration

xs:dayTimeDuration A ne B

function:gregorian-not-equal xs:boolean Gregorian Gregorian A ne B

function:hex-binary-not-equal xs:boolean xs:hexBinary xs:hexBinary A ne B

function:base64-binary-not-equal xs:boolean xs:base64Binary

xs:base64Binary A ne B

function:anyURI-not-equal xs:boolean xs:anyURI xs:anyURI A ne B

function:QName-not-equal xs:boolean xs:QName xs:QName A ne B

function:NOTATION-not-equal xs:boolean xs:NOTATION xs:NOTATION A ne B

function:integer-greater-than xs:boolean xs:integer xs:integer A gt B

function:decimal-greater-than xs:boolean xs:decimal xs:decimal A gt B

function:boolean-greater-than xs:boolean xs:boolean xs:boolean A gt B

function:string-greater-than xs:boolean xs:string xs:string A gt B

function:date-greater-than xs:boolean xs:date xs:date A gt B

function:time-greater-than xs:boolean xs:time xs:time A gt B

function:datetime-greater-than xs:boolean xs:dateTime xs:dateTime A gt B

function:yearMonthDuration-greater-than


xs:yearMonthDuration A gt B

function:dayTimeDuration-greater-than


xs:dayTimeDuration A gt B

function:integer-less-than xs:boolean xs:integer xs:integer A lt B


function:decimal-less-than xs:boolean xs:decimal xs:decimal A lt B

function:boolean-less-than xs:boolean xs:boolean xs:boolean A lt B

function:string-less-than xs:boolean xs:string xs:string A lt B

function:date-less-than xs:boolean xs:date xs:date A lt B

function:time-less-than xs:boolean xs:time xs:time A lt B

function:datetime-less-than xs:boolean xs:dateTime xs:dateTime A lt B

function:yearMonthDuration-less-than


xs:yearMonthDuration A lt B

function:dayTimeDuration-less-than


xs:dayTimeDuration A lt B

function:integer-greater-than-or-equal

xs:boolean xs:integer xs:integer A ge B

function:decimal-greater-than-or-equal

xs:boolean xs:decimal xs:decimal A ge B

function:string-greater-than-or-equal

xs:boolean xs:string xs:string A ge B

function:date-greater-than-or-equal

xs:boolean xs:date xs:date A ge B

Function:time-greater-than-or-equal

xs:boolean xs:time xs:time A ge B

Function:datetime-greater-than-or-equal

xs:boolean xs:dateTime xs:dateTime A ge B

Function:yearMonthDuration-greater-than-or-equal


xs:yearMonthDuration A ge B

Function:dayTimeDuration-greater-than-or-equal


xs:dayTimeDuration A ge B

Function:integer-less-than-or-equal

xs:boolean xs:integer xs:integer A le B

Function:decimal-less-than-or-equal

xs:boolean xs:decimal xs:decimal A le B

Function:numeric-less-than-or-equal

xs:boolean xs:string xs:string A le B

Function:date-less-than-or-equal xs:boolean xs:date xs:date A le B

Function:time-less-than-or-equal xs:boolean xs:time xs:time A le B

Function:datetime-less-than-or-equal

xs:boolean xs:dateTime xs:dateTime A le B


Function:yearMonthDuration-less-than-or-equal


xs:yearMonthDuration A le B

Function:dayTimeDuration-less-than-or-equal


xs:dayTimeDuration A le B

Function:string-match xs:boolean xs:string xs:string

Function:and xs:boolean xs:boolean xs:boolean A & B

Function:or xs:boolean xs:boolean xs:boolean A | B

Function:ordered-or xs:boolean xs:boolean xs:boolean A | B

Function:n-of xs:boolean numeric xs:boolean

Function:not xs:boolean xs:boolean (only one operand allowed)

Function:present xs:boolean xs:anyURI

Function:subset xs:boolean xs:list xs:list

Function:superset xs:boolean xs:list xs:list

Function:non-null-set-intersectionxs:boolean xs:list xs:list


Appendix B. XACML identifiers (normative)

B.1. XACML identifiersThis section defines standard identifiers for commonly used entities. All XACML-defined identifiers have the common base:

urn:oasis:names:tc:xacml:1.0

B.2. XACML nNamespacesThere are currently two defined XACML namespaces.

Policies are defined using this identifier.

urn:oasis:names:tc:xacml:1.0:policy

Input and output contexts are defined using this identifier.

urn:oasis:names:tc:xacml:1.0:context

B.3. Authentication lLocalityThe following identifiers indicate the location where an authentication act occurredcredentials were activated. They are intended to support the corresponding entities from the SAML authentication statement.

This identifier indicates that the location is expressed as an IP address.

urn:oasis:names:tc:xacml:1.0:authn-locality:ip-address

This identifier indicates that the location is expressed as a DNS name.

urn:oasis:names:tc:xacml:1.0:authn-locality:dns-name

B.4. Access sSubject cCategoriesThis identifier indicates the system entity that is directly requesting access, that is the final entity in a request chain. If subject category is not specified, this is the default value.

urn:oasis:names:tc:xacml:1.0:subjectcategory:access-subject

This identifier indicates the system entity that will receive the results of the request. Used when it is distinct from the access-subject.

urn:oasis:names:tc:xacml:1.0:subjectcategory:recipient-subject

This identifier indicates a system entity through which the request was passed. There may be more than one. No means is provided to specify the order in which they passed the message.

urn:oasis:names:tc:xacml:1.0:subjectcategory:intermediary-subject


3462

3463

34643465

3466

3467

3468

3469

3470

3471

3472

3473

347434753476

3477

3478

3479

3480

3481

34823483

3484

34853486

3487

34883489

3490

114

This identifier indicates a system entity associated with a local or remote codebase that generated the request. Corresponding subject aAttributes might include the URLfrom which it was loaded from and/or signature the identity of the code-signer. There may be more than one. No means is provided to specify the order they passed the message.

urn:oasis:names:tc:xacml:1.0:subjectcategory:codebase

This identifier indicates a system entity associated with the computer that initiated the request. An example would be an IPsec identity.

urn:oasis:names:tc:xacml:1.0:subjectcategory:requesting-machine

B.5. XACML functionsThis identifier is the base for all the identifiers in the table of functions. See Appendix A.1.

urn:oasis:names:tc:xacml:1.0:function

B.6. Data tTypesThe following identifiers indicate useful datatypes.

B.5.1.X.500 distinguished nameThis identifier indicates an X.500 distinguished name.

urn:oasis:names:tc:xacml:1.0:datatype:x500name

B.5.2.RFC822 NameThis identifier indicates an RFC822-style name.

urn:oasis:names:tc:xacml:1.0:datatype:rfc822name

B.5.3.Unix file-system pathThis identifier indicates a UNIX file-system path.

urn:oasis:names:tc:xacml:1.0:datatype:ufs-path

B.5.4.NumericThis identifier indicates a numeric value.

urn:oasis:names:tc:xacml:1.0:datatype:numeric

B.6. Date TypesThe following date identifiers are defined by XML Schema.

http://www.w3.org/2001/XMLSchema:yearMonthDuration


3491349234933494

3495

34963497

3498

3499

3500

3501

3502

3503

3504

3505

3506

3507

3508

3509

3510

3511

3512

3513

3514

3515

3516

3517

3518

115

http://www.w3.org/2001/XMLSchema:dayTimeDuration

http://www.w3.org/2001/XMLSchema:Gregorian

B.7. Environment attributesThis identifier indicates the current time at the PDP. In practice it is the time the input context was created.

urn:oasis:names:tc:xacml:1.0:environment:current-time

B.8. Subject aAttributesThese identifiers indicate attributes of a subject. At most one of each of these aAttributes is associated with each subject. Each attribute associated with authentication relates to the same authentication event.

This identifier indicates the name of the subject. The default format is xs:string. To indicate other formats, use <AttributeValue DataType="<format>" data type attributes listed in B.6.

urn:oasis:names:tc:xacml:1.0:subject:subject-id

This identifier indicates the subject category. Access-subject is the default.

urn:oasis:names:tc:xacml:1.0:subject:subject-category

This identifier indicates the security domain of the subject. Identifies the administrator and policy that manages the name-space in which the subject id is administered.

urn:oasis:names:tc:xacml:1.0:subject:subject-id-qualifier

This identifier indicates a public key used to confirm the subject’s identity.

urn:oasis:names:tc:xacml:1.0:subject:key-info

This identifier indicates the time at which the subject was authenticated.

urn:oasis:names:tc:xacml:1.0:subject:authentication-time

This identifier indicates the method used to authenticate the subject.

urn:oasis:names:tc:xacml:1.0:subject:authentication-method

This identifier indicates the time at which the subject initiated the access request, according to the PEP.

urn:oasis:names:tc:xacml:1.0:subject:request-time

This identifier indicates the time at which the subject’s current session began, according to the PEP.

urn:oasis:names:tc:xacml:1.0:subject:session-start-time

Add the LDAP attributes.


35193520

35213522

3523

35243525

3526

3527

352835293530

35313532

3533

3534

3535

35363537

3538

3539

3540

3541

3542

3543

3544

35453546

3547

35483549

3550

3551

116

B.9. Resource aAttributesThis identifier indicates the entire URI of the resource.

urn:oasis:names:tc:xacml:1.0:resource:resource-uri

This identifier indicates the last (rightmost) component of the file name. For example, if the URI is: “file://home/my/status#pointer”, the simple-file-name is "status".)

urn:oasis:names:tc:xacml:1.0:resource:simple-file-name

This identifier indicates that the resource is specified by an XPath expression.

urn:oasis:names:tc:xacml:1.0:resource:xpath

B.10. Status cCodesThe following status code identifiers are defined.

This identifier indicates success.

urn:oasis:names:tc:xacml:1.0:status:ok

This identifier indicates that attributes necessary to make a policy decision where not available.

urn:oasis:names:tc:xacml:1.0:status:missing-attribute

This identifier indicates that some attribute value contained a syntax error, such as a letter in a numeric field.

urn:oasis:names:tc:xacml:1.0:status:syntax-error

This identifier indicates that an error occurred during policy evaluation. An example would be division by zero.

urn:oasis:names:tc:xacml:1.0:status:processing-error

B.11. Combining aAlgorithms

B.10.1. Deny-overrides rule-combining algorithmThe deny-overrides rule-combining algorithm has the following value for ruleCombiningAlgId:

urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:deny-overrides

B.10.2. Deny-overrides policy-combining algorithmThe deny-overrides policy-combining algorithm has the following value for policyCombiningAlgId:

urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides

B.10.3. Permit-overrides rule-combining algorithmThe permit-overrides rule-combining algorithm has the following value for ruleCombiningAlgId:

urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides


3552

3553

3554

35553556

3557

3558

3559

3560

3561

3562

3563

3564

3565

35663567

3568

35693570

3571

3572

3573

3574

3575

3576

3577

3578

3579

3580

3581

117

B.10.4. Permit-overrides policy-combining algorithmThe permit-overrides policy-combining algorithm has the following value for policyCombiningAlgId:

urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:permit-overrides

B.10.5. First-applicable rule-combining algorithmThe first-applicable rule-combining algorithm has the following value for ruleCombiningAlgId:

urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable

B.10.6. First-applicable policy-combining algorithmThe first-applicable policy-combining algorithm has the following value for policyCombiningAlgId:

urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:first-applicable

B.11. Identifiers Used Only In XACML Identifiers used only in XACML cConformance tTests

All identifiers used in conformance tests will use this identifier as a base.

urn:oasis:names:tc:xacml:1.0:conformance-test

B.12. Attributes uUsed iIn eExamplesThe following subject attributes are defined for the purpose of giving examples. Application environments are expected to define their own identifiers as needed.

urn:oasis:names:tc:xacml:1.0:example:attribute

urn:oasis:names:tc:xacml:1.0:example:attribute:group

urn:oasis:names:tc:xacml:1.0:example:attribute:role

B.13. Actions uUsed in eExamplesThis identifier is used as the base for actions used in examples.

urn:oasis:names:tc:xacml:1.0:example:action

urn:oasis:names:tc:xacml:1.0:example:action:xml-ac


3582

3583

3584

3585

3586

3587

3588

3589

3590

3591

3592

3593

3594

3595

35963597

3598

35993600

36013602

3603

3604

3605

36063607

118

Appendix C. Combining algorithms (normative)This section contains a description of the rule-combining and policy-combining algorithms specified by XACML.

C.1. Deny-overridesThe following specification defines the "Deny Overrides" rule- combining algorithm of a policy.

In the entire set of rules to be evaluated, if any rule evaluates to "Deny", then the result of the rule combination shall be "Deny". If any rule evaluates to "Permit" and all other rules evaluate to "NotApplicable", then the result of the combination shall be "Permit". In other words, "Deny" takes precedence, regardless of the result of evaluating any of the other rules in the combination. If all rules are found not to be "NotAapplicable" to the decision request, then the rule combination returns "NotApplicable".

If there is any error evaluating the ttarget or condition of a rule that contains an effect of "Deny" then the evaluation continues looking for a result of "Deny". If no other rule evaluates to a "Deny", then the result of the combination is "Indeterminate".

If at least one rule evaluates to "Permit", all other rules that do not have evaluation errors evaluate to "Permit" or "NotApplicable", and all rules that do have evaluation errors contain effects of "Permit", then the result of the combination shall be "Permit".

The following pseudo- code represents the evaluation strategy of this rule- combining algorithm.

Decision denyOverridesRuleCombiningAlgorithm(Rule rules[]){Boolean atLeastOneError = false;Boolean potentialDeny = false;Boolean atLeastOnePermit = false;for( i=0 ; i < lengthOf(rules) ; i++ ){

Decision decision = evaluate(rules[i]);if (decision == Deny){

return Deny;}if (decision == Permit){

atLeastOnePermit = true;continue;

}if (decision == NotApplicable){

continue;}if (decision == Indeterminate){

atLeastOneError = true;

if (effectOf(rules[i]) == Deny){

potentialDeny = true;}

draft-xacml-specification-16.doc

115

3608

36093610

3611

3612

361336143615361636173618

361936203621

362236233624

3625

36263627362836293630363136323633363436353636363736383639364036413642364336443645364636473648364936503651365236533654

119

120

continue;}

}if (potentialDeny){

return Indeterminate;}if (atLeastOnePermit){

return Permit;}if (atLeastOneError){

return Indeterminate;}return NotApplicable;

}

The following specification defines the "Deny Overrides" policy- combining algorithm of a policy set.

In the entire set of policies to be evaluated, if any policy evaluates to "Deny", then the result of the policy combination shall be "Deny". In other words, "Deny" takes precedence, regardless of the result of evaluating any of the other policiesy in the combination. If all policies are found not to be "NotAapplicable" to the decision request, the policy combination returns "NotApplicable".

If there is any error evaluating the target of a policy, or a reference to a policy is considered invalid, or the policy evaluation results in "Indeterminate", then the result of the combination shall be "Deny".

The following pseudo- code represents the evaluation strategy of this policy-combining algorithm.

Decision denyOverridesPolicyCombiningAlgorithm(Policy policies[]){Boolean atLeastOnePermit = false;for( i=0 ; i < lengthOf(policies) ; i++ ){

Decision decision = evaluate(policies[i]);if (decision == Deny){


atLeastOnePermit = true;continue;

}if (decision == NotApplicable){


return Deny;}

}if (atLeastOnePermit){

return Permit;}


36553656365736583659366036613662366336643665366636673668366936703671

36723673

36743675367636773678

367936803681

36823683

3684368536863687368836893690369136923693369436953696369736983699370037013702370337043705370637073708370937103711

121

return NotApplicable;}

Obligations of the individual policies shall be combined as described in Section 4.3.2.3."Obligations."

C.2. Permit-overridesPermit Overrides Decision Rule Combining Algorithm

The following specification defines the "Permit Overrides" rule-combining algorithm of a policy.

In the entire set of rules to be evaluated, if any rule evaluates to "Permit", then the result of the rule combination shall be "Permit". If any rule evaluates to "Deny" and all other rules evaluate to "NotApplicable", then the result of the combination shall be "Deny". In other words, "Permit" takes precedence, regardless of the result of evaluating any of the other rules in the combination. If all rules are found not to be "NotAapplicable" to the decision request, then the rule combination returns "NotApplicable".

If there is any error evaluating the target or condition of a rule that contains an effect of "Permit" then the evaluation continues looking for a result of "Permit". If no other rule evaluates to a "Permit", then the result of the combination is "Indeterminate".

If at least one rule evaluates to "Deny", all other rules that do not have evaluation errors evaluate to "Deny" or "NotApplicable", and all rules that do have evaluation errors contain effects of "Deny", then the result of the combination shall be "Deny".

The following pseudo- code represents the evaluation strategy of this rule-combining algorithm.

Decision permitOverridesRuleCombiningAlgorithm(Rule rules[]){Boolean atLeastOneError = false;Boolean potentialPermit = false;Boolean atLeastOneDeny = false;for( i=0 ; i < lengthOf(rules) ; i++ ){


atLeastOneDeny = true;continue;

}if (decision == Permit){

return Permit;}if (decision == NotApplicable){


atLeastOneError = true;

if (effectOf(rules[i]) == Permit){

potentialPermit = true;}


37123713

37143715

3716

3717

3718

371937203721372237233724

372537263727

372837293730

3731

37323733373437353736373737383739374037413742374337443745374637473748374937503751375237533754375537563757375837593760

122

continue;}

}if (potentialPermit){

return Indeterminate;}if (atLeastOneDeny){

return Deny;}if (atLeastOneError){


}

The following specification defines the "Permit Overrides" policy-combining algorithm of a policy set.

In the entire set of policies to be evaluated, if any policy evaluates to "Permit", then the result of the policy combination shall be "Permit". In other words, "Permit" takes precedence, regardless of the result of evaluating any of the other policiesy in the combination. If all policies are found not to be "NotAapplicable" to the decision request, the policy combination returns "NotApplicable".

If there is any error evaluating the target of a policy, a reference to a policy is considered invalid, or the policy evaluation results in "Indeterminate", then the result of the combination shall be "Indeterminate" only if no other policies evaluate to "Permit" or "Deny".

The following pseudo- code represents the evaluation strategy of this policy-combining algorithm.

Decision permitOverridesPolicyCombiningAlgorithm(Policy policies[]){Boolean atLeastOneError = false;Boolean atLeastOneDeny = false;for( i=0 ; i < lengthOf(policies) ; i++ ){

Decision decision = evaluate(policies[i]);if (decision == Deny){

atLeastOneDeny = true;continue;

}if (decision == Permit){



atLeastOneError = true;continue;

}}


37613762376337643765376637673768376937703771377237733774377537763777

37783779

37803781378237833784

3785378637873788

37893790

37913792379337943795379637973798379938003801380238033804380538063807380838093810381138123813381438153816

123

if (atLeastOneDeny){

return Deny;}if (atLeastOneError){


}

Obligations of the individual policies shall be combined as described in Section 4.3.2.3."Obligations."

C.3. First-a Applicable Rule Combining AlgorithmThe following specification defines the "First-Applicable Determinate" rule-combining algorithm of a policy.

Each rule is evaluated in the order it is listed in the policy. Of a particular rule, if the target is applicablematches and the condition evaluates to "Ttrue", the evaluation of the combination shall halt and the corresponding effect of the rule shall be the result of the evaluation of the combination (i.e. "Permit" or "Deny"). Of a particular rule selected in the evaluation, if the target does not matchis not applicable or the condition evaluates to "Ffalse", then the next rule in the order is evaluated. If no further rule in the order exists, then "NotApplicable" shall be the result of the evaluation of the combination.

If there is any error evaluating the target or condition of a rule then the evaluation shall halt, and the result shall be "Indeterminate" with the appropriate error status.

The following pseudo- code represents the evaluation strategy of this rule-combining algorithm.

Decision firstApplicableEffectRuleCombiningAlgorithm(Rule rules[]){for( i = 0 ; i < lengthOf(rules) ; i++ ){





return Indeterminate;}

}return NotApplicable;

}

The following specification defines the "First- Appplicable" policy-combining algorithm of a policy set.


3817381838193820382138223823382438253826

38273828

3829

38303831

3832383338343835383638373838

38393840

3841

384238433844384538463847384838493850385138523853385438553856385738583859386038613862386338643865

38663867

124

Each policy is evaluated in the order thate it appears in the policy set. Of a particular policy, if the target is applicablematches and the policy evaluates to a determinate decision of "Permit" or "Deny", the evaluation shall halt and that effect shall be the result of the evaluation of the combination. Of a particular policy, if the target does not matchis not applicable or the policy evaluates to "NotApplicable", then the next policy in the order is evaluated. If no further policy exists in the order, then "NotApplicable" shall be the result of the evaluation of the combination.

If there is any error evaluating the target or the policy, or a reference to a policy is considered invalid, then the evaluation shall continue looking for an applicable policy, if no applicable policy is found, then the result of the combination is "Indeterminate".

The following pseudo- code represents the evaluation strategy of this policy-combination algorithm.

Decision firstApplicableEffectPolicyCombiningAlgorithm(Policy policies[]){Boolean atLeastOneError = false;for( i = 0 ; i < lengthOf(policies) ; i++ ){

Decision decision = evaluate(policies[i]);if(decision == Deny){

return Deny;}if(decision == Permit){



atLeastOneError = true;continue;

}}if (atLeastOneError){


}

Obligations of the individual policies shall be combined as described in Section 4.3.2.3"Obligations."


3868386938703871387238733874

387538763877

38783879

3880388138823883388438853886388738883889389038913892389338943895389638973898389939003901390239033904390539063907390839093910

39113912

125

Appendix D. AcknowledgmentsThe following individuals were voting members of the XACML committee at the time that this version of the specification was issued:

Affinitex James MacLean [email protected] Crosslogix Ken Yagen [email protected] Crosslogix Daniel Engovatov [email protected] Entegrity Hal Lockhart [email protected] Entrust Carlisle Adams [email protected] Entrust Tim Moses [email protected] Hitachi Don Flinn [email protected] Hitachi Konstantin Beznosov [email protected] Overxeer Bill Parducci [email protected] Overxeer Simon Godik [email protected] IBM Michiharu Kudoh [email protected] Polar Humenn [email protected] Sterling Commerce Suresh Damodaran [email protected] University of Milan Pierangela Samarati [email protected] University of Milan Ernesto Damiani [email protected] Sun Microsystems Sekhar Vajjhala [email protected] Microsystems Anne Anderson [email protected] Xtradyne Gerald Brose [email protected]


3913

39143915

391639173918391939203921392239233924392539263927392839293930393139323933

126

Appendix E. Revision hHistoryRev Date By whom What

V14 14 June 2002 Tim Moses Added the XACML context schema. Added the Security and Privacy section.

V15 18 July 2002 Tim Moses Changed the representation of <Function>

V16 16 Aug 2002 Tim Moses Updated policy schema, identifiers, combining algorithms. Deleted LDAP profile.


3934

3935

127

Appendix F. NoticesOASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.

OASIS has been notified of intellectual property rights claimed in regard to some or all of the contents of this specification. For more information consult the online list of claimed rights.

OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.

Copyright (C) OASIS Open 2002. All Rights ReservedCopyright © The Organization for the Advancement of Structured Information Standards [OASIS] 2001. All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an “AS IS” basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


3936

393739383939394039413942394339443945

39463947

3948

394939503951

39523953

39543955395639573958395939603961

39623963

39643965396639673968

128

d9db56472fd41226d193 …… · Web viewMichiharu Kudo, IBM, Japan. Pierangela Samarati, University...

Documents

Transcript of d9db56472fd41226d193 …… · Web viewMichiharu Kudo, IBM, Japan. Pierangela Samarati, University...