Attribute based access control

The Discovery attribute based access control language is presented as a JSON based profile of the XACML language, modified to use the information model query language (SPARQL) to express policy rules and use of the semantic ontology attributes.

The language is used to support some of the data access authorisation processes as described in the specification - Identity, authentication and authorisation .

This article specifies the scope of the language and the grammar it uses, together with examples. Whilst presented as a JSON syntax, in line with other components of the information modelling language, the syntax can also be accessed via the Information model XSD schemaon the discovery Github, and example content viewed in the information manager data files folder

Scope of ABAC language and approach

The language is designed to support a conversation between a client application and a policy decision point, with a intermediary; the policy enforcement point, brokering the exchange.

RBAC-> ABAC

The conversations are constrained, consisting of a request, an assessment and a decision, and a response. The application makes a request to it's policy enforcement point (PEP). The PEP packages the request and passes it to the Policy decision point (PDP). The PDP examines the request and looks for policies relevant to the request and decides whether the request can be granted. It passes the response back to the PEP. If the request is granted the PDP may also oblige the PEP to perform some other activity as part of the action. The PEP returns the response to the application. The application may also need to understand the obligations in respect of the access, although this could be delegated to the PEP.

Requests are also constrained. ABAC specialises in requests for access to some function or data in order to perform some action. Requests are assessed in the context of the characteristics of the request, the requester, and a policy which is stored in the Policy information point (PIP). Responses are simply permit, deny, not relevant or indeterminate, with perhaps some obligations or advice associated with the response.

There is no assumption within the language as to the infrastructure or the physical separation of concerns between the client, the PEP, or the PDP. In practice, a PEP may be a component within an application and a PDP may be implemented in process also, although it is recommended that a PDP is implemented as a server accessed via REST API.

It is strongly recommended that readers of this specification familiarise themselves with ABAC and have an overall understanding of the main concepts in XACML.

In line with the rest of the information language, the ABAC language consists of a small number of tokens (reserved words), referencing the vocabulary of attributes and value types via the ontology. Much of the ABAC rule language is dispensed with as being replaced by SPARQL ASK clause which is in effect a Graph matching clause.

Policy related language tokens

Policies are considered concepts and as such inherit core concept attributes including the IRI, name, description, status, code and code scheme.

Policies involve the use the following structures:

Main ABAC policy structures

• PolicySet - A set of policies brought together to resolve policy combinations or to maintain common outcomes. A policy set may contain other policy sets as well as policies. A policy set may contain a target

• Policy - A set of rules (including a combining rule) that deals with a type of request. A policy may contain a target

• Rule - A description of the decision that will be taken. A rule may contain a target or condition type rule.

• Target - An index that indicates that a policy set or policy or rule is the target of a request. The target is itself a rule
• CombiningAlgorithm - Logical resolution where rules or policies product conflicting results

Attribute category tokens

The term attribute category is an ABAC term but is a bit of misnomer. Attribute categories exist in order to signal the business nature of the attributes that are of part of a request or policy. In Discovery, as categories are limited to the main 4 types and the use of them they can be treated as tokens . The categories are:

• Subject - Describes the subject that is requesting access, or describes the attributes of subjects required to grant or refuse permission. A typical example of a subject would be a user and their role
• AccessSubject - Indicates that a subject is requesting access and therefore attributes relate to the subject requesting access e.g. a user in role.

• Resource - Describes the module, function or data that the requester is attempting to access, or when used in a policy, the nature of the resource that may determine whether or not permission is granted

• Action - Describes the action that will be performed in relation to the resource, or when used in a policy, the nature of the action that may determine whether or not permission is granted

• Environment - describes environmental conditions that may be tested for, e.g. time of day.

XACML defines additional attribute categorisation of subject in order to redirect the responses such as Recipient subject These are not supported in this version.

Attributes and how they are defined

Attributes are properties and values describing subjects, resources, actions and the environment. Attributes are modelled in the common information model ontology like any other property such as health record property. Consequently, they also share the same semantic definitions. This allows ABAC attributes to be treated like any other e.g. query, subsumption query, data storage.

The conversation that exists between the application and the PDP often involves the exchange of subject attributes e.g. attributes of a user or the user in a role. Obviously there must be a common understanding of the meaning of those attributes. In other words an attribute of a user must mean the same thing as an attribute of a policy that is testing the user's attributes.

To take matter one step further, it is also important that the designers of application functionality understand the attributes that the ABAC policy uses to determine permissions. If an application is going to make a request for access using attributes of the subject or resource then they must match. The information model enables that exchange to take place without the need to map between the application and the PDP. More specifically, it is the PEP context manager than normally performs this mapping, so that is made substantially easier by using the same language.