Difference between revisions of "SOA3 Authorization Module"

From Gcube Wiki
Jump to: navigation, search
m
m
Line 64: Line 64:
  
 
*'''Policy Management Interface''' receives ''policies management requests'', translates them into XACML form and forwards the generated message to PAP's SOAP web interface. The component leverages the full power of XACML syntax by '''XACML generator''' in order to perform CRUD operations on policies. In particular it allows to create, read, update, and delete both policies and ''policy sets''. Policy Sets management is useful in very dynamic environments, such as cloud environment, providing the quick insertion and deletion of sets of policies related on dynamic resources.
 
*'''Policy Management Interface''' receives ''policies management requests'', translates them into XACML form and forwards the generated message to PAP's SOAP web interface. The component leverages the full power of XACML syntax by '''XACML generator''' in order to perform CRUD operations on policies. In particular it allows to create, read, update, and delete both policies and ''policy sets''. Policy Sets management is useful in very dynamic environments, such as cloud environment, providing the quick insertion and deletion of sets of policies related on dynamic resources.
−
 
+
*'''Web GUI''' is a Portlet integrated into IMarine Portal providing a graphical presentation of policy management operations. It is decoupled from Policy Management Interface and communicates with it by using the web service REST interface. Web GUI is strictly integrated with IMarine infrastructure, in particular it leverages IS services in order to load the services list (representing the ''resources'') and available roles (representing the most important attributes).
−
 
+
*'''Policy Administration Point''' is a storage for the policies. It exposes two SOAP web services, one for managing policies and one for providing policies for decisions. PAP receives the policies in XACML format from Policy Management Interface and stores them in the same format.  
−
 
+
*'''Policy Decision Point''' takes authorization decisions basing on policies and attributes. It has two web service interfaces:
−
 
+
**''Policy Decision Query'' interface receives XACML Policy Decision Query messages containing attributes, action id and resource id and returns an ''Authorization Response'' stating if the authorization has been grant
−
 
+
**''Policy provisioning'' interface asks PAP for policies and receives them
−
The '''Authorization Interface''' element is the contact point between the Authorization Module and the gCube infrastructure. Three kind of interfaces are provided:
+
*'''Policy Enforcement Point''' receives Policy Authorization requests containing call and caller attributes, resource id and action label, adds environment attributes, creates Policy Decision Query messages and forwards them to PDP Policy Decision Query interface. PEP contains two sub-modules:
−
*XACML, using the standard protocol request message, in particular SAML2.0 profile of XACML2.0 with SOAP transport
+
**''Attribute Manager'', which retrieves any extra attribute required for the decision. In particular some extra attributes could be stored in the user LDAP and not be carried by the request: Attribute Manager leverage User Management module in order to load those attributes from user storage
−
*REST
+
**''Policy Information Point'', part of Attribute Manager, specialized in loading and managing environment attributes, such as time or date
−
*Java Api for strict integration of the Authorization module with [[gCube Security Handler]]
+
*'''Authorization interface''' is the connector between PEP XACML Authorization Request interface and the world external to SOA3. This interface can work in three different ways:
−
 
+
**transparent way, forwarding XACML requests to PEP
−
[[gCube Security Handler]] should contact the Authorization System through these interfaces, in particular:
+
**as a web service converter, receiving REST messages containing authorization request information and generating the XACML message
−
*XACML interface is the same interface exposed by PEP, so it means to contact the PEP directly
+
**as a java connector integrated into the external application 
−
*REST interface provides a method which hides all the complexity of the system, allowing only to ask if an user is authorized and receive the response
+
In gCube context, in order to remove all the possible dependencies, the REST interface is used for interconnecting [[gCube Security Handler]] to SOA3 Authorization Module
−
*Java API means that it is possible to totally integrate the interface in the Request Interceptor as Java Library using some exposed API to contact the PEP
+
−
 
+
−
[[gCube Security Handler]] flexibility provides the possibility to choice any of these interfaces.
+
−
 
+
−
The '''PEP''' is a canonical Policy Enforcement Point, which enforces the decision evaluated by the PDP. The element is extended with an internal Attribute Manager which manages two categories of attributes:
+
−
*local user attributes
+
−
*context attributes
+
−
it not only contacts the PEP, but also acts as ''Dynamic Attribute Manager'' and ''Contextual Attribute Manager''.
+
−
The Dynamic Attributes are, for example:
+
−
 
+
−
*number of access performed by that user
+
−
*last access time
+
−
 
+
−
The attributes are accessed through the UserManagement Module by web services in read-only mode.
+
−
The update operation of dynamic attributes is outside the scope of the authorization system. They should be updated by an external accounting-billing system, since the attributes manager is able only to read these attributes.
+
−
 
+
−
The PIP adds contextual attributes, i.e. attributes with no relationship with the user, such as:
+
−
*date and time
+
−
*virtual organization status
+
−
*global infrastructure status
+
−
 
+
−
These attributes, called in XACML terminology, environment attributes, are used to take decision based also on external factors.
+
−
The other components play the same role described above, in particular:
+
−
*PDPs elaborate the policy decision
+
−
*PAP provides the required policies
+
−
Caching and load balancing mechanism are provided to improve the performances and the availability of the system.
+
−
 
+
−
;Current status
+
−
The current implementation status is the following:
+
−
* the PEP is integrated in gCube security Handler by Java API interface, XACML interface is available and REST interface should be completed
+
−
* context attribute support will be available during the next steps of the project
+
−
* the other functionalities are under test
+
  
  

Revision as of 17:22, 20 March 2012

Overview

Authorization is the function of specifying access rights to resources and enforcing the taken decisions. There are diverse Authorization models: SOA3 Authorization Module bases its decisions on stored policies by which it is able to determine if a subject can perform a certain action on a certain resource. Since the subject is defined by a set of attributes referred to the caller, the call and the environment, the adopted model is defined as Attribute Based Access Control (ABAC) [1]. ABAC is a very flexible model, which can be view as a generalization of Role Based Access Control[2], where the only allowed attributes are roles.

In particular the module:

  • receives Authorization Requests containing caller and call related attributes from gCube Security Handler
  • evaluates if the caller is authorized to perform a certain action basing the decision on received attributes, environment attributes and stored policies
  • returns Authorization Responses to gCube Security Handler

GCube Security Handler could contact SOA3 Authorization Module in different ways: in particular a strict integration could be obtained by using Java Library API or it is possible to have looser dependencies by web service interfaces, SOAP and RESTful. In order to obtain a zero-dependencies model the RESTful interface is used sending the following parameters:

  • call and caller attributes, at least user role
  • requested service's id, representing the resource in authorization terms
  • requested operation's label, representing the action


Key features

Attribute Based Access Control Model
a very general and extensible model which base the decisions on a set of attributes from the caller, the call and the environment
Policy based decisions
the decisions are based on a set of pre-defined policies stored
Standard based architecture
the module is based on the standard eXtensible Access Control Markup Language (XACML) [3]
Graphical policies management interface
a portlet is available to define and manage policies
Extensible set of attributes
Possibility to configure the attributes set to be used for policies evaluation
High availability
redundancy and load balancing for improving performance

Design

Philosophy

The module provides Authorization as a Service, in particular gCube Security Handler sends a REST request to the exposed web service and receives an authorization response. The module is totally decoupled from gCore: the only connector is gCube Security Handler, which generates REST requests and interprets SOA3 responses. Modularity and compliance to XACML standard has a paramount importance, in fact from the architecture is very easy to distinguish the four main modules of a canonical XACML Authorization architecture:

  • Policy Administration Point (PAP)
  • Policy Decision Point (PDP)
  • Policy Enforcement Point (PEP)
  • Policy Information Point (PIP)

The use of XACML standard and the presence of clearly identified modules makes the architecture extensible and manageable.

XACML standard and the presented architecture is totally agnostic on the semantic of data included in the requests: in other words SOA3 doesn't make any hypothesis on the meaning of the attributes, resource ids or action labels. This provides a very strong flexibility on policies composition and attributes or id assignment.


Architecture

SOA3 Authorization Module

The architecture is based on the features provided by Argus Authorization Framework [4], which provides the first functionalities of PAP, PDP, PEP and PIP. SOA3 Authorization Module added value is the possibility to consider more than an attribute to take decisions and, more in general, to manage complex policies.

  • Policy Management Interface receives policies management requests, translates them into XACML form and forwards the generated message to PAP's SOAP web interface. The component leverages the full power of XACML syntax by XACML generator in order to perform CRUD operations on policies. In particular it allows to create, read, update, and delete both policies and policy sets. Policy Sets management is useful in very dynamic environments, such as cloud environment, providing the quick insertion and deletion of sets of policies related on dynamic resources.
  • Web GUI is a Portlet integrated into IMarine Portal providing a graphical presentation of policy management operations. It is decoupled from Policy Management Interface and communicates with it by using the web service REST interface. Web GUI is strictly integrated with IMarine infrastructure, in particular it leverages IS services in order to load the services list (representing the resources) and available roles (representing the most important attributes).
  • Policy Administration Point is a storage for the policies. It exposes two SOAP web services, one for managing policies and one for providing policies for decisions. PAP receives the policies in XACML format from Policy Management Interface and stores them in the same format.
  • Policy Decision Point takes authorization decisions basing on policies and attributes. It has two web service interfaces:
    • Policy Decision Query interface receives XACML Policy Decision Query messages containing attributes, action id and resource id and returns an Authorization Response stating if the authorization has been grant
    • Policy provisioning interface asks PAP for policies and receives them
  • Policy Enforcement Point receives Policy Authorization requests containing call and caller attributes, resource id and action label, adds environment attributes, creates Policy Decision Query messages and forwards them to PDP Policy Decision Query interface. PEP contains two sub-modules:
    • Attribute Manager, which retrieves any extra attribute required for the decision. In particular some extra attributes could be stored in the user LDAP and not be carried by the request: Attribute Manager leverage User Management module in order to load those attributes from user storage
    • Policy Information Point, part of Attribute Manager, specialized in loading and managing environment attributes, such as time or date
  • Authorization interface is the connector between PEP XACML Authorization Request interface and the world external to SOA3. This interface can work in three different ways:
    • transparent way, forwarding XACML requests to PEP
    • as a web service converter, receiving REST messages containing authorization request information and generating the XACML message
    • as a java connector integrated into the external application

In gCube context, in order to remove all the possible dependencies, the REST interface is used for interconnecting gCube Security Handler to SOA3 Authorization Module


Deployment

GCube Authorization module should be deployed per Virtual Organization: in particular there should exist a module for each VO and the module should protect all the resources belonging to that VO.

Large deployment

The maximum scalability is obtained using load balancers between PDP and PAP, PEP and PDP and also Authorization interfaces and PEP. The diagram is similar to the architecture diagram above.

Small deployment

A minimal solution is the following:

Minimal Authorization Module

Use Cases

Since the subsystem is currently under test there are no "success stories" available

Notes

  1. ↑ http://en.wikipedia.org/wiki/Access_control#Attribute-based_access_control
  2. ↑ http://en.wikipedia.org/wiki/Role-based_access_control
  3. ↑ http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml#XACML20
  4. ↑ https://twiki.cern.ch/twiki/bin/view/EGEE/AuthorizationFramework
Retrieved from "https://wiki.gcube-system.org/index.php?title=SOA3_Authorization_Module&oldid=13813"