Difference between revisions of "GCube Security Handler"

From Gcube Wiki
Jump to: navigation, search
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 component works like a workflow engine triggered by every request received by the container. Every task of the workflow ends with a response which could be ''true'' or ''false'': if all the responses are true, the request is considered authenticated and authorized. If one of these response is false the workflow stops and a ''security fault'' is returned.
+
The sub-components involved in this process are:
−
Actually only a task is called: this task contacts the Policy Based Facilities, which, basing on the policies defined, takes a decision on the request and provides the response. The request contains a set of '''user related attributes''' (currently, only the ''VO related Role''), a resource value (the name of the service or resource requested) and an action (the method requested).  
+
*'''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
  
−
 
−
 
−
The GCube Handler is the element which intercepts all the requests and passes it to the ''Security Handler''.
 
−
;Current status
 
−
Currently the Handler has not workflow support yet, but calls only two configurable tasks, one for ''Authentication'' and one for ''Authorization''. The authentication task is used only in particular client configuration: in general in the container the security is assured by TLS+Authorization calling the authorization task which, in turn, calls [[gCube Authorization Module]]
 
  
 
== Deployment ==
 
== Deployment ==
−
GCube Security Handler is a module deployed as library in gCore platform
+
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

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 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.

Well suited Use Cases

Not so well suited Use Cases

Retrieved from "https://wiki.gcube-system.org/index.php?title=GCube_Security_Handler&oldid=13830"