Difference between revisions of "SOA3 Authorization Module"
| Line 73: | Line 73: | ||
*PAP provides the required policies | *PAP provides the required policies | ||
Caching and load balancing mechanism are provided to improve the performances and the availability of the system. | Caching and load balancing mechanism are provided to improve the performances and the availability of the system. | ||
| + | |||
| + | 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:50, 2 March 2012
Overview
The subsystem receive Authorization Requests from gCube Security Handler module and provides Authorization Responses based on:
- static user attributes, in particular roles
- dynamic user attributes, for example the number of accesses made by the user during the day
- context attributes, for example date and time
Key features
- Standard based architecture
- In particular the whole subsystem is based on the standard eXtensible Access Control Markup Language (XACML)
- Extensible set of attributes
- It is possible to configure the attributes to be used for policies evaluation
- High availability architecture
- It is possible to add redundancy and load balancing for improving the performances
Design
Philosophy
A canonical XACML based architecture is composed by:
- Policy Administration Point (PAP)
- Policy Decision Point (PDP)
- Policy Enforcement Point (PEP)
- Policy Information Point (PIP)
The architecture is fully compliant with this specification: the open source software Argus Authorization Framework provides some of the required functionalities. The interaction with gCube Security Handler and the management of dynamic attributes need some extra features.
Architecture
The architecture is depicted in the following figure:
The Authorization Interface element is the contact point between the Authorization Module and the gCube infrastructure. Three kind of interfaces are provided:
- XACML, using the standard protocol request message, in particular SAML2.0 profile of XACML2.0 with SOAP transport
- REST
- Java Api for strict integration of the Authorization module with gCube Security Handler
gCube Security Handler should contact the Authorization System through these interfaces, in particular:
- XACML interface is the same interface exposed by PEP, so it means to contact the PEP directly
- 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
- 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.
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
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:
Use Cases
Since the subsystem is currently under test there are no "success stories" available
