SOA3 Connector

Overview

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

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

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

The server module is the SOA3 Connector Service: it exposes a single REST interface allowing clients to requst authentication and authorization. If required, it contacts SOA3 Authentication and Authorization Services: it has to be noted that the need for 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

The library provides the Message Level Security controller on received messages, leveraging the common-security library for managing the Credentials.

The class org.gcube.security.soa3.connector.SOA3SecurityController can be used as a filter on all the incoming messages, in order to check the security related information (Message Level security header and TLS Certificate DN) and the authentication and authorization privileges. At first it asks a local cache, and, if there is not information, the request is forwarded to SOA3Connector Service. The answer (successful or fail), is stored in the cache in case of other calls using 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 Node.

In particular, org.gcube.security.soa3.connector.SOA3SecurityController implements the interface org.gcube.security.soa3.connector.GCUBESecurityController providing four public methods:

• init which accepts as parameters a Map of java Strings
• checkAccess which accepts as parameters a Map of java Objects
• isSecurityEnabled which returns a boolean
• setSecurityEnabled which accepts a boolean

The two last methods are straightforward, while, for SOA3 implementation:

• The init method should be called a single time for filter initialization: in the parameters Map only an entry is required:
  • Key = SERVICE_NAME: the name of the service protected by this instance of the filter
• The checkAccess method should be called when the filter is applied, with the following parameters in the map:
  • Key = BinarySecurityToken: which is a java String representing the Security Header
  • Key = PEER_SUBJECT: a javax.security.auth.Subject representing the authenticated subject of the call
  • Key = SERVICE_STRING: a java String representing the service target of the request. In general the representation is ServiceClass:ServiceName
  • Key = SERVICE_INSTANCE: a java String representing the Node on which the service target of the request is deployed (the actual instance). It is represented as HostName:port and, typically, it is the same web server where the security filter provided by the library is active

GSS Integration Library

The library is a bridge between theGCube Server Security Integration Library and GSS stack used in the GHN.

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 configurations described above in org.gcube.security.soa3.connector.SOA3SecurityController class, which actually extecutes the controls. The library also assure compatibility between the GSS stack used in Globus based GHN and the common-security library. This integration level will be outcast when the FWS will be adopted for all gCube.

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 provided exists (DN Based Authentication)

Identity propagation based on tickets

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