Authorization Framework

The gCube Authorization framework is a token based authorization system in a gCube-based infrastructure. This framework in compliant with the Attribute-based access control (ABAC) that defines an access control paradigm whereby access rights are granted to users through the use of policies which combine attributes together. ABAC defines access control based on attributes which describe:

• the requesting entity (either the user or the service),
• the targeted resource (either the service or the resource),
• the desired action (read, write, delete, execute),
• and environmental or contextual information (either the VRE or the VO where the operation is executed).

ABAC is a logical access control model that is distinguishable because it controls access to objects by evaluating rules against the attributes of the entities (requesting entity or target resource) actions and the environment relevant to a request. ABAC relies upon the evaluation of attributes of the requesting entity, attributes of the targeted resource, environment conditions, and a formal relationship or access control rule defining the allowable operations for entity-resource attribute and environment condition combinations.

The model

Token based authorization

The token is a string generated on request by the Authorization service for identification purposes and associated with every entity belonging to a gCube-based infrastructure (users or services). The token is passed in every call and is automatically propagated in the lower layers. The token can be passed to a Smartgears service in 2 ways:

• using the HTTP-header: adding the value ("gcube-token","{your-token}") to the header parameters.
• using the query-string: adding gcube-token={your-token} to the existing query-string
• logging via authentication widget using username and token.

The Policy Language

The gCube Auhtorization Framework controls access to applications to allow or prevent the clients to perform various operations in the application. This is controlled by the Auhtorization Service embedded in the Smartgears framework with the help of authorization policies. The purpose of authorization policies is to control clients access. The authorization policies determine at runtime whether or not a particular action is denied. You can define authorization policies that satisfy the authorization requirements using the policy language.

All the policies created in the system are used to DENY to a client an operation in a specific context. Two types of policy are supported:

• User2Service (U2S)
• Service2Service (S2S)

The U2S policies are used to deny to an user or a role the acces to specific service or class of services. The S2S policies are used to deny to a service or a class of services the acces to specific service or class of services. To make easier the possibility to allow access only to few clients an except restriction is defined in the policies.

For every policy a specific ACTION to prevent can be added (if supported from the service) otherwise all the ACTION will be denied:

• ALL (default)
• ACCESS
• WRITE
• DELETE
• EXECUTE

Examples

• U2S(context, User('myUserName'), Service(ServiceClass, ServiceName, ServiceIdentifier ) )

• U2S(context, Role('role'), Service(ServiceClass, ServiceName, ServiceIdentifier ) )

• U2S(context, allExcept[Role('role1'), Role('role2')], Service(ServiceClass, ServiceName, ServiceIdentifier ) )

• S2S(context, Service(ServiceClass1, ServiceName1, ServiceIdentifier), Service(ServiceClass2, ServiceName2, ServiceIdentifier2 ) )

• S2S(context, Service(ServiceClass1, ServiceName1, ServiceIdentifier), Service(ServiceClass2, *) )

• S2S(context, allExcept[Service(ServiceClass1, ServiceName1,*)], Service(*))

The System Architecture

The Authorization framework is compliant with the XACML reference architecture. XACML is the OASIS standard for fine-grained authorization management based on the concept of Attribute-based access control (ABAC), where access control decisions are made based on attributes associated with relevant entities while operating in a given operational context, a natural evolution from Role Based Access Control (RBAC).

The XACML standard proposes a reference architecture with commonly accepted names for the various entities involved in the architecture. The nomenclature is not new (SAML uses similar names to describe entities in its ecosystem), nor is the architecture complicated, allowing for easier common base of understanding of the standard. It is composed by 5 modules

• Policy Administration Point (PAP) - Point which manages access authorization policies
• Policy Decision Point (PDP) - Point which evaluates access requests against authorization policies before issuing access decisions
• Policy Enforcement Point (PEP) - Point which intercepts user's access request to a resource, makes a decision request to the PDP to obtain the access decision (i.e. access to the resource is approved or rejected), and acts on the received decision
• Policy Information Point (PIP) - The system entity that acts as a source of attribute values (i.e. a resource, subject, environment)
• Policy Retrieval Point (PRP) - Point where the XACML access authorization policies are stored, typically a database or the filesystem.

The 5 modules' capabilities are implemented by gCube as follow.

• Policy Administration Point (PAP) is the gCube Authorization Service
• Policy Decision Point (PDP) is implemented by a PDP library distributed with gCube SmartGears
• Policy Enforcement Point (PEP) is implemented by a PEP library distributed with gCube SmartGears
• Policy Information Point (PIP) is implemented by the gCube Information System
• Policy Retrieval Point (PRP) is implemented by a database controlled exclusively by the gCube Authorization Service

The following flow of control governs the authorization flow.

The policy author uses policy authoring tools (GUI) (part of the PAP) to write policies governing access and exploitation of his/her own resources.

The policy administrator then uses the PAP GUI to administer the policies. Please note that policies are not distributed to PDPs upon their creation but at first request referring access/exploitation of a given resource. PDPs use a cache with TTL to avoid the exchange of too many requests.

The PEP intercepts the business level request to access the resource decorated with a token. It resolves the token by sending a request to the PAP and gets back information about the validity of the token to operate in the specific operational context. If the access is denied (invalid token) a Deny Response is immediately issued. If the access is permitted the request to the PAP allows to populate the PDP cache with the appropriate policies. Then it produces a request out of it and sends it to the PDP for actual decision making.

The PDP, on receiving the request, looks up the policies deployed on it and figures out the ones which are pertinent to the specific request. It may, if necessary, query the PIP for additional attributes that are needed to evaluate the policies. By exploiting the attributes contained in the request, the attributes obtained from the PIP and attributes that are generic to the operational context, the PDP decides whether the request can be allowed (Permit response), denied (Deny response), is not applicable since none of the policies deployed on it can be used to evaluate the request (NotApplicable response) or there was some issue with evaluating the response against the policy, for example due to lack of sufficient attributes available to the PDP (Indeterminate response).

The response is then sent by the PDP to the PEP. The PEP parses the response from the PDP and handles each of the four possible response cases. If either a Permit or a NotApplicable response is get back then the business request is passed to the service, otherwise a Deny response is issued.

Client Library

Client library has a specific wiki page: Authorization client Library

Service installation

Please refer to the Authorization service installation page.