Difference between revisions of "SOA3 Connector"

Revision as of 13:05, 12 March 2013

Overview

SOA3 Connector is the implementation if the architectural module described in GCube Security Handler: it is a complex element composed by a client module and a server module. The client module is composed by:

• common-security library
• gcube-server-security-integration library

it can be integrated with the container or with a standalone client, provides a caching mechanism and acts as client for SOA3 Connector Service.

The server module is SOA3 Connector Service: it exposes a single REST interface allowing clients to obtain authentication and authorization. If required, it contacts SOA3 Authentication and Authorization Services: the need of these operations is limited by a caching mechanism.

Architecture

The deployment model is described in the following picture:

SOA3 Connector

Every node contains a client library which performs the controls on the requests and, if needed, asks SOA3 throught SOA3 Connector Service. The Connector Service acts as a single endpoint providing authentication and authorization in a single step

Client library

The structure of the Client Library is described in the following picture:

SOA3 Connector Client Library

It is the actual implementation of GCube Security Handler, which incercepts incoming messages, checks the security privileges and sets the credentials for outgoing messages.

Common Security Library

Common-security library, based on the FeatherWeightStack, allows to manage the credentials used by gCube. The rationale of the library is described in Client Security Library, and an example of integration is given in GCube Clients Integration with security.

The core of the library is the CredentialManager, InheritableThreadLocal, where it is possible to set and get the credentials for the current thread. In particular, in a GHN each service can use its credentials with its propagation policy: the InheritableThreadLocal feature allows to get specific Service Credentials, if set, or default container credentials otherwise. The library includes org.gcube.soa3.connector.common.security.handlers.SOA3Handler, an implementation of org.gcube.common.clients.stubs.jaxws.handlers.CallHandler, dynamically loaded using Java ServiceLoader feature. SOA3Handler adds the Message Security Header to the outgoing message without any explicit intervention of the User or the Developer. The handler works also for TLS: if a specific certificate is associated to a certain service and is defined using common-security X509TLSCredentials class, SOA3Handler adds the certificate to the specific request for the specific service (using the InheritableThreadLocal feature).

The described features are valid for both clients running in a GHN and standalone clients.

GCube Server Security Integration Library

This library is a bridge between the Common Security Library and GSS stack used in the GHN. It also provides the implementation of the classes providing the controls to be performed on received messages. The main control class is org.gcube.security.soa3.connector.integration.server.SOA3IntegrationSecurityController: it implements the interface org.gcube.common.core.security.GCUBEServiceAuthorizationController, used in the old version of gCube Security Framework. This class sets the security configuration in org.gcube.security.soa3.connector.SOA3SecurityController class, which actually extecutes the controls. The two levels of encapsulation are due to the compatibility with the current version of GCF: in the next versions, which will use less features of GSS framework, the Integration Library will be progressively deprecated, allowing to use directly only the common-security library and few control classes. The class org.gcube.security.soa3.connector.SOA3SecurityController is called by GCubeHandler, intercepts all the incoming messages, checks the security related information (Message Level security header and TLS Certificate DN) and checks the authentication and authorization privileges. At first it asks a local cache, and, if there are no information, the request is forwarded to SOA3Connector Service. The answer (successful or fail), is stored in the cache in case of other call with the same credentials. In case of successful authentication, if the identity propagation is enabled, the controller sets a TicketCredentials object in the CredentialManager to be used if the request should be propagated to another GHN.

SOA3 Connector Service

SOA3 Connector Service is a REST Service, running under Tomcat, acting as a single endpoint for SOA3 Authentication and Authorization Services. It is design to limit the amount of REST requests needed to obtain access and, at the same time, be scalable and suitable to a distributed environment. The REST Service exposed distinguishes four different authentication requests:

• Username/Password Authentication
• Federated Authentication
• DN Authentication
• Ticket based Authentication

The Service includes a configurable internal cache, which is the first module to be interrogated for all the kinds of request. If the cache doesn't contain entries or contains an expired entry about the request, the call is parsed basing on its nature. In particular:

• Username/Password and Federated Authentication requests are dispatched to (SOA3 Authentication Service).
• DN Authentication is performed by checking if an User with the DN provider exists (User Management Service)

Ticket based Authentication

A ticket is produced as a consequence of a successful authentication: the ticket defines a security session and is valid untill the information in SOA3 Connector Service cache are expired. This means that, in general, a Ticket based Authentication request must be processed using only the local cache. This consideration is true if and only if only a single instance of SOA3 Connector Service exists. This is not true in gCube ecosystem, so there are use cases in which a ticket has been produced by another instance of SOA3.

The ticket is a Base64 encoded string with the following structure:

 Base64(serviceId::local_ticket)

The serviceid identifies the instance of SOA3 which has produced the ticket (SOA3 originator instance) and must be known and trusted, for security reasons, by the instance which receives the Authentication request. If the Authentication Query result is not present in the local cache, and SOA3 originator instance is different by the local instance, SOA3 Connector Service retrieves the endpoint of the SOA3 originator instance (currently by a local configuration file) and forwards the message. The originator instance authenticates the request (asking to its local cache) and, for successful authentication, sends the expiration time of the ticket. The local instance stores the new ticket with its expiration time in the local cache for any other request.