Difference between revisions of "GCube Security Handler"
m |
m |
||
Line 39: | Line 39: | ||
[[Image:SecurityHandler.jpg|frame|center|Security Handler]] | [[Image:SecurityHandler.jpg|frame|center|Security Handler]] | ||
+ | GCube Handler acts as a filter passing every received message to GCube Security Handler: the message is passed in its original form (HTTPMessage Object or SOAPMessage Object). After the elaboration, which in general, involves at least a call to SOA3 (apart from caching), GCube Security Handler returns a message communicating if the ''caller is authenticated'', if the ''request is authorized'' and, if applicable, a text message with the reason of the decision. | ||
− | The | + | The sub-components involved in this process are: |
− | + | *'''REST Connector''', which forwards the authentication and authorization messages to SOA3 | |
+ | * '''Message Parser''', which receives the messages forwarded from gCube Handler and extracts security related information: the sub-component is the actual connector, because it contains a part strictly related to gCore API, by which it must get the message, and another part which composes the message for SOA3 | ||
+ | **'''SAML consumer''' is specialized in extraction and parsing of SAML assertions. A message coming from gCube infrastructure, sent from an already authenticated user, is not requested to propagate the credentials. Anyway, to guarantee the authentication and the identity of the caller it could transport a SAML assertion: it is not mandatory, the syntax of user informations depends on the message, but if the assertion is present, it must be consumed | ||
+ | *'''Security Engine''' is the workflow engine which executes the security related tasks. This tasks could be authentication or authorization tasks and be an arbitrary number: the response of each task determines the response of the security process. Each task could involve a call to SOA3 by REST Connector | ||
− | |||
− | |||
− | |||
− | |||
− | |||
== Deployment == | == Deployment == | ||
− | GCube Security Handler is a | + | GCube Security Handler is a library deployed with gCore container, so there is not any particular deployment schema to be proposed. |
+ | |||
+ | ==Use cases== | ||
+ | |||
+ | The use cases covered by gCube Security Handler are described in this section. | ||
+ | |||
+ | ===Well suited Use Cases=== | ||
+ | |||
+ | |||
+ | ===Not so well suited Use Cases=== |
Revision as of 17:10, 21 March 2012
Overview
GCube Security Handler is the Connector between the SOA3 and the rest of gCube system. It performs the following operations:
- receives from gCube Handler the messages containing the requests and addressed to gCube managed resources
- extracts the data useful for security related processes
- sends the appropriated calls to SOA3
- on the basis of received response, asks the container to accept or refuse the request
In particular it is a gCore module which intercepts the requests for a service and ask the Authorization module if the caller is authorized.
Key features
- Transparent connection between SOA3 and gCube
- the module decouples totally SOA3 from gCube allowing Web Services based communication and reducing direct dependencies
- Extensible architecture
- the design allows to add other security related modules not necessarily based on SOA3
- Support for multiple message types
- the parser extracts data from an extensible set of messages: currently SOAP and simple HTTP. The data are found by configurable pattern matching
- Workflow structure
- Security related operations and REST calls are performed calling a configurable series of workflow tasks
Design
Philosophy
Since the module is a connector, it must link and decouple gCore framework with SOA3 framework: the module has a paramount importance in a zero-dependencies model. As a connector, the module is composed by two parts: the first one is related to gCore and is strictly linked to gCore libraries; the second one generates and send the messages to SOA3, so it is REST based. The architecture is extensible, in the sense that the workflow engine can manage different tasks, not only SOA3 services related tasks: this means that if other operations, not only SOA3 related, are required, the module is easily extensible.
Architecture
GCube Handler acts as a filter passing every received message to GCube Security Handler: the message is passed in its original form (HTTPMessage Object or SOAPMessage Object). After the elaboration, which in general, involves at least a call to SOA3 (apart from caching), GCube Security Handler returns a message communicating if the caller is authenticated, if the request is authorized and, if applicable, a text message with the reason of the decision.
The sub-components involved in this process are:
- REST Connector, which forwards the authentication and authorization messages to SOA3
- Message Parser, which receives the messages forwarded from gCube Handler and extracts security related information: the sub-component is the actual connector, because it contains a part strictly related to gCore API, by which it must get the message, and another part which composes the message for SOA3
- SAML consumer is specialized in extraction and parsing of SAML assertions. A message coming from gCube infrastructure, sent from an already authenticated user, is not requested to propagate the credentials. Anyway, to guarantee the authentication and the identity of the caller it could transport a SAML assertion: it is not mandatory, the syntax of user informations depends on the message, but if the assertion is present, it must be consumed
- Security Engine is the workflow engine which executes the security related tasks. This tasks could be authentication or authorization tasks and be an arbitrary number: the response of each task determines the response of the security process. Each task could involve a call to SOA3 by REST Connector
Deployment
GCube Security Handler is a library deployed with gCore container, so there is not any particular deployment schema to be proposed.
Use cases
The use cases covered by gCube Security Handler are described in this section.