Difference between revisions of "Authorization Framework"

From Gcube Wiki
Jump to: navigation, search
(The System Architecture)
Line 21: Line 21:
  
 
== The System Architecture ==
 
== 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
  
 
== Configuration Overview ==
 
== Configuration Overview ==

Revision as of 16:52, 15 February 2016

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 Policy Language

Examples

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

Configuration Overview

The service runs on a smartgears node.

It relies on a postgresSQL instance to store the created tokens.