Difference between revisions of "GCube Security Handler"

Revision as of 12:40, 22 March 2012

Overview

GCube Security Handler is a gCore module acting as a Connector between SOA3 and the rest of gCube system. It performs the following operations:

• receives from gCube Handler messages containing requests for gCube managed resources
• extracts data useful for security related processes
• sends authentication and/or authorization requests to SOA3
• on the basis of received response, asks the container to accept or refuse resource requests

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

Security Handler

GCube Handler acts as a message interceptor, 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 the following:

• REST Connector forwards the authentication and authorization messages to SOA3
• Message Parser receives the messages coming from gCube Handler and extracts security related information: the sub-component is the actual connector, because it contains a message retrieving part strictly related to gCore API, a request generating part generating messages for SOA3, independent from gCure technology
  • If that message transports a SAML assertion guaranteeing the authentication and the identity of the caller, SAML consumer extracts and parse this assertion
  • If the message doesn't support SAML assertions, message-depending data transports are defined and compliant data extraction methods are configurable through configuration file. In particular for non-SOAP HTTP messages, credentials are inserted in HTTP authentication header and roles in a special-purpose header
• Security Engine is the workflow engine executing security related tasks. These tasks could be an arbitrary number of authentication or authorization tasks: the response of each task determines the response of the whole 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.

Well suited Use Cases

GCube Security Handler plays a role in two main use cases:

• Authentication of calls coming from external infrastructures or external clients
• Authorization

The first use case concerns the calls originated from standalone clients. If one of these clients requires a certain resource, the request message must contain the credentials of the user who asks for that resource. In this case the handler is configured to find attached credentials and to send an authentication request to SOA3. SOA3 answers with a SAML authentication assertion containing user attributes which can be used for authorization purposes.

The first use case doesn't concern, in general, messages propagated from Node to Node: in this case the user has previously performed the authentication and the message has attached only caller's attributes. The second use case concerns all the calls requesting a managed resource: in this case the call contains caller attributes, gCube Security Handler gets them from the message and sends an Authorization Request to SOA3.

Less well suited Use Cases

GCube Security Handler accesses security related data (credentials and/or attributes) in read-only-mode. This means that it is not designed to manage any form of propagation of this information. In particular attribute propagation policies, or scope propagation policies should be managed at different levels of gCube architecture: credential propagation is not secure, unless it is in the form of delegation.