Abbreviated Language for Authorization Version 1.0



Abbreviated Language for Authorization Version 1.0

Working Draft 01

10 March 2015

Technical Committee:

OASIS eXtensible Access Control Markup Language (XACML) TC

Chairs:

Hal Lockhart (hal.lockhart@), Oracle

Bill Parducci (bill@), Individual

Editors:

Pablo Giambiagi (pablo@), Axiomatics

Srijith K. Nair (srijith.nair@), Axiomatics

David Brossard (david.brossard@), Axiomatics

Additional artifacts:

This prose specification is one component of a Work Product that also includes:

• XML schemas: (list file names or directory name)

• Other parts (list titles and/or file names)

Related work:

This specification replaces or supersedes:

• Specifications replaced by this specification (hyperlink, if available)

This specification is related to:

• Related specifications (hyperlink, if available)

Declared XML namespaces:

• list namespaces declared within this specification

Abstract:

The aim of this profile is to propose a domain-specific language for an abbreviated high-level description of XACML authorization policies. The XACML policy syntax is specified in the core XACML specification. This profile leverages it.

Status:

This Working Draft (WD) has been produced by one or more TC Members; it has not yet been voted on by the TC or approved as a Committee Draft (Committee Specification Draft or a Committee Note Draft). The OASIS document Approval Process begins officially with a TC vote to approve a WD as a Committee Draft. A TC may approve a Working Draft, revise it, and re-approve it any number of times as a Committee Draft.

URI patterns:

Initial publication URI:



Permanent “Latest version” URI:



(Managed by OASIS TC Administration; please don’t modify.)

Copyright © OASIS Open 2015. All Rights Reserved.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

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 section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, 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 OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Table of Contents

1 Introduction 5

1.1 Terminology 5

1.2 Normative References 5

1.3 Non-Normative References 5

1.4 Scope 5

2 Notations 6

3 ALFA language structure 7

3.1 Concepts 7

3.2 Overview of the XACML elements and their corresponding ALFA elements 7

3.3 Identifiers 8

3.4 Comments 8

3.4.1 Example 8

3.5 Namespace 8

3.5.1 Example 9

3.5.2 Organization 9

3.6 Scoping 9

3.6.1 Example 9

3.7 Rule 10

3.7.1 Example 10

3.8 Policy 11

3.8.1 Example 11

3.9 Policy Set 11

3.9.1 Example 12

3.10 Targets 12

3.10.1 Example 12

3.11 Conditions 13

3.11.1 Example 13

3.12 Constant Values 13

3.12.1 Example 13

3.13 Attributes 14

3.13.1 Attribute declarations 14

3.13.2 Example 14

3.13.3 Attribute Designators 14

3.13.4 Example 14

3.14 Atomic attributes and bags 14

3.14.1 Example 15

3.15 Obligation and Advice 15

3.15.1 Declaration 15

3.15.2 Example 15

3.15.3 Usage 15

3.15.4 Example 15

3.15.5 Example 16

3.16 Operator declarations 17

3.16.1 Example 17

3.16.2 Operator inverses 18

3.16.2.1 Example 18

3.16.3 Bag overloading 18

3.16.3.1 Example 19

3.17 Operator precedence 19

3.18 Function declarations 19

3.18.1 Example 20

3.19 Combing algorithm declarations 20

3.19.1 Example 20

3.20 Category declarations 21

3.20.1 Example 21

3.21 Attribute declarations 21

3.21.1 Example 21

4 Compiling into XACML 22

5 XACML Coverage 23

5.1 Deviations from XACML 23

5.1.1 Order of the parameters in a Target function 23

5.1.2 Use of the condition in policy and policy sets 23

5.1.3 Existence of rules on their own 23

5.1.4 Default translation of functions in conditions 23

5.2 Unsupported features 23

6 #Conformance 24

Appendix A. Acknowledgments 25

Appendix B. Default ALFA identifiers 26

B.1 Combining algorithms 26

B.1.1 Rule combining algorithms 26

B.1.2 Policy combining algorithms 26

B.1.3 Functions 27

B.1.4 Datatatypes 27

Revision History 28

1. Introduction

[All text is normative unless otherwise labeled]

(Non-normative)

The XACML language model provides a comprehensive but complex language syntax for expressing access control policies and rules. Since the original design in 2001 and in later versions up to 2014, the de-facto format chosen to represent XACML is XML. XML and the XML schema provide a easy means to formally define a declarative language grammar.

However, XML is both extremely verbose and hard to read for humans. The XACML grammar is also a rich grammar. The combination of these aspects lead to an XML representation of XACML which is hard to edit by hand.

Abbreviated Language for Authorization (ALFA) is a domain-specific language for a high-level description of XACML policies. It is designed with ease of use in mind, for use by XACML policy writers. ALFA provides the means to present domain specific information, such as attribute identifiers, in compact form and lays down the basic principle to compile policies expressed in ALFA into XACML 3.0 policies.

ALFA does not bring new semantics to XACML. Anything that can be expressed in ALFA must be expressible in XACML.

ALFA has been designed in such a way that lossless round-trip translations is possible.

1 Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].

2 Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997. .

[XACML30] OASIS Standard, "eXtensible Access Control Markup Language (XACML) Version 3.0", April 2010.

[CombAlg] OASIS Committee Specification Draft 03, "XACML 3.0 Additional Combining Algorithms Profile Version 1.0", April 2014.

3 Non-Normative References

4 Scope

This profile specifies the form and establishes the interpretation of policies written in the ALFA language. It specifies:

▪ the representation of ALFA policies

▪ the syntax and constraints of the ALFA language

▪ the semantic rules for interpreting ALFA policies

This profiles does not specify:

▪ all minimum requirements of a translator that is capable of translating ALFA policies into XACML policies.

Notations

ALFA language structure

1 Concepts

The ALFA language, being a pseudo-code representation of XACML, inherits the overall structure and concepts of the XACML language.

[pic]

Figure 1 - Policy language model from [XACML30]

2 Overview of the XACML elements and their corresponding ALFA elements

|XACML |ALFA |Description |

|PolicySet |policyset | |

|Policy |policy | |

|Rule |rule | |

|Condition |condition | |

|Effect |Either of permit or deny. |There is no Effect element in ALFA. The user |

| | |can directly insert the value. |

|Target |target | |

|AnyOf |or | |

|AllOf |and | |

|Policy Combining Algorithm |apply | |

|ObligationExpression |obligation | |

|AdviceExpression |advice | |

|RuleCombiningAlgorithm |apply | |

3 Identifiers

Literal identifiers are of the form 3, -10, 2.2, true, false, ‘hello’, “hello” etc.

Valid identifiers for obligations, advices, functions, attributes and categories are characters followed by zero or more characters mixed with any number of numbers., i.e. ('a-zA-Z_' ('a-zA-Z_0-9)*)

Valid infix identifiers are &&, ||, >, ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download