Difference between revisions of "SOA3 Authorization Module"

Latest revision as of 16:29, 8 May 2013

Overview

Authorization is the function of specifying access rights to a resource and enforcing 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 caller, call and environment, the adopted model is defined as Attribute Based Access Control (ABAC) ^[1]. ABAC can be considered as a generalization of Role Based Access Control^[2]: it is a very flexible model where the original notion of role is generalized in a set of attributes.

The module performs the following actions:

• 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

A client could be strictly integrated to SOA3 Authorization Module, by using it as a Java Library, or have looser dependencies by Web Service interfaces, SOAP and RESTful. In order to obtain a zero-dependencies model, gCube Security Handler contacts SOA3 Authorization Module by REST calls 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 generic and extensible model which base the decisions on a set of attributes from caller, call, and environment

Policy-driven decisions

the decisions are based on a set of pre-defined stored policies

Standard based architecture

the module is based on the standard eXtensible Access Control Markup Language (XACML) 2.0 ^[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: this approach assures minimal dependencies between gCube and SOA3 Authorization Module. Modularity and compliance to XACML standard have 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 adoption of XACML standard and the presence of clearly identified modules make the architecture extensible and manageable.

According to XACML standard, the architecture is completely 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 very strong flexibility on policies composition and attributes or id assignment.

Architecture

SOA3 Authorization Module

The architecture is based on the features of Argus Authorization Framework ^[4], which provides the first functionalities of PAP, PDP, PEP and PIP. SOA3 Authorization Module builds upon these features in order to easily configure policies based on more than one attribute and, more in general, manage the complex use cases raised by the D4Science e-Infrastructure.

• 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 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 syntax from Policy Management Interface and stores them.
• 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, by SOA3 User Management Module, loads those attributes from user storage
  • Policy Information Point is the 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. In order to reduce the number of calls, cache mechanisms are implemented, in particular:

• gCube Security Handler Cache caches the results of authorization requests
• PEPc Cache caches PEP decisions
• PEP Cache caches PDP decisions
• PDP Cache caches the policies loaded from PAP
• User Management Cache caches the results of attribute requests

Deployment

SOA3 Authorization module should be deployed per Virtual Organization: anyway, for especially for testing purposes, it could be deployed at infrastructure level.

Large deployment

SOA3 Authorization Module is recommended to be deployed at Virtual Organization Level. In particular Policy Management Portlet, which represents Policy Management Web GUI should be deployed on the portal at VO level and should point to the deployment of SOA3 Authz module related to its VO. Each gCube Hosting Node has an instance of gCube Security Handler running on it: each instance should point to its VO related Authz module. Attribute storage, not shown in the figure, is not part of SOA3 and is the user management database: it is deployed at infrastructure level, so each SOA3 instance must point to the same storage (through the same SOA3 User Management Module instance).

SOA3 Authorization Module Deployment

Small deployment

For testing purposes, i.e. with a low load, it is possible to deploy a single instance of SOA3 Authorization Module at infrastructure level. Policy Management Portlet is deployed on infrastructure portal at infrastructure level pointing to the single Authz Module instance. This deployment model is applicable only for low loads because it might create a bottleneck at Authorization Interface level, since every Node of the infrastructure will send Authz requests to such a single module.

Use Cases

The use cases covered by SOA3 Authorization Module are described in this section.

Well suited Use Cases

SOA3 Authorization Module allows complete management of authorization process in gCube infrastructure. In particular it provides:

• easy policy definition and management even for non-skilled user by Policy Management Portlet
• quick and effective policy evaluation, with a strong look at performance using load balancing and caching between modules

The possibility to load policy sets into Policy Management Interface is useful in dynamic resource management: for example if a VRE is defined under a VO, it is possible to load a policy set based on VRE attributes granting authorization privileges to the users belonging to that VRE for that VRE's resources.

Less well suited Use Cases

Service Level Agreement (SLA) ^[5] management relates to the definition and the enforcement of certain service features determining the quality of that service. An example of SLA policy regarding the use of system resource is the following:

user U has an assigned memory consumption lower or equal than X: if U requires more memory than X, grant the extra memory if and only if there are not other users who need it (best effort).

Since a similar policy is not an authorization policy, SOA3 currently doesn't support a similar use case. In particular:

• SOA3 Authz Module can access user attributes in read only mode and cannot update dynamically system related parameters, such as memory consumption
• SOA3 Authz Module provides only boolean (authorized or not) answers to an authorization request: a best effort approach or a conditional authorization is out of canonical authorization scope

Anyway, under the following two hypotheses:

• an external module, keeping system related attributes up to date, is provided
• we can accept only two answers, i.e. authorized or not authorized, or, in other words, if U doesn't respect her SLA is kicked out from the system

then, SLA management becomes more similar to authorization management and some, very limited, use cases could be covered.

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
5. ↑ http://en.wikipedia.org/wiki/Service-level_agreement