Difference between revisions of "GCube Security Handler"

From Gcube Wiki
Jump to: navigation, search
(→‎Overview)
 
(20 intermediate revisions by 3 users not shown)
Line 5: Line 5:
 
== Overview ==
 
== Overview ==
  
−
'''GCube Security Handler''' is the ''Connector'' between the Authorization Module and the rest of gCube system. In particular it is a gCore module which intercepts the requests for a service and ask the Authorization module if the caller is authorized.
+
'''GCube Security Handler''' is a gCore module acting as a ''Connector'' between SOA3 and the rest of the 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
 +
*forwards authentication and/or authorization requests to SOA3
 +
*on the basis of received response, asks the container to accept or refuse resource requests
  
 
=== Key features ===
 
=== Key features ===
  
−
;Workflow structure
+
;Transparent connection between SOA3 and gCube
−
:The architecture of the module is generic: it is potentially possible to configure different task in order to check different security related features. Currently the module uses only a single task to contact, by XACML requests, the Policy Based Security Facilities.
+
:the module decouples SOA3 from gCube allowing Web Services based communication and reducing direct dependencies
  
−
;XML configuration
+
;Extensible architecture
−
:The module is configurable by gCube container configuration files
+
: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 ==
 
== Design ==
  
 
=== Philosophy ===
 
=== Philosophy ===
−
The module represents the connector between the Policy Based Facilities and the rest of gCube infrastructure. It is a flexible and extendible component which is strictly integrated in gCube platform: every request for the container is intercepted and triggers the start of the workflow.
+
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 sends the messages to SOA3, and 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 can easily accommodate them.
  
 
=== Architecture ===
 
=== Architecture ===
−
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.
 
−
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).
 
  
−
 
 
[[Image:SecurityHandler.jpg|frame|center|Security Handler]]
 
[[Image:SecurityHandler.jpg|frame|center|Security Handler]]
  
−
The GCube Handler is the element which intercepts all the requests and passes it to the ''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 involves at least a call to SOA3 (apart from caching), GCube Security Handler returns a message stating if the ''caller is authenticated'', if the ''request is authorized'' and, if applicable, a text message with the reason of the decision.
−
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]]
+
 
 +
The sub-components involved in this process are the following:
 +
*'''[[SOA3 Connector|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 the gCore technology
 +
**If that message transports a SAML assertion guaranteeing the authentication and the identity of the caller, the ''SAML consumer'' extracts and parses 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 ==
 
== 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===
 +
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 manages 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 manage, 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: credentials propagation is strongly discouraged  because it is not a secure operation, unless it is performed in form of '''delegation'''.

Latest revision as of 12:15, 10 December 2013

Overview

GCube Security Handler is a gCore module acting as a Connector between SOA3 and the rest of the 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
  • forwards 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 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 sends the messages to SOA3, and 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 can easily accommodate them.

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 involves at least a call to SOA3 (apart from caching), GCube Security Handler returns a message stating 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 the gCore technology
    • If that message transports a SAML assertion guaranteeing the authentication and the identity of the caller, the SAML consumer extracts and parses 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:

  1. Authentication of calls coming from external infrastructures or external clients
  2. Authorization

The first use case manages 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 manage, 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: credentials propagation is strongly discouraged because it is not a secure operation, unless it is performed in form of delegation.

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