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

• Policy Sets - 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
• Combining algorithms - Logical resolution where rules or policies product conflicting results

Attribute categories

The term attribute category is an ABAC term but is a bit of misnomer. Attribute categories exist in order to signal the intention of part of a request or policy rule in relation to a set of attributes. 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

• 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

Attributes and how they are defined

Attributes are properties and values describing subjects, resources, actions and the environment. Attributes are

The values of object properties are usually instances of classes as modelled in the ontology. Consequently entailment can be processed with the query to enable policy rules to capture classes of attributes.