Difference between revisions of "SOA3 Connector"

Latest revision as of 11:14, 10 December 2013

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 checks on the incoming requests and, if needed, contacts SOA3 through the 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 the GCube Security Handler, which intercepts 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 the Client Security Library section, and an example of integration is given in the GCube Clients Integration with security section.

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 within 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 the org.gcube.soa3.connector.common.security.handlers.SOA3Handler, an implementation of the org.gcube.common.clients.stubs.jaxws.handlers.CallHandler, dynamically loaded using Java ServiceLoader feature. SOA3Handler adds the Message Security Header to the outgoing message transparently. The handler works also for TLS: if a specific certificate is associated to a service and it is defined using the common-security X509TLSCredentials class, the SOA3Handler includes 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 further 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 in case the request have to be propagated to another Node.

In particular the 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 invoked once 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 invoked 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 the ServiceClass:ServiceName
  • Key = SERVICE_INSTANCE: a java String representing the Node where 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 the gCube Server Security Integration Library and GSS stack used in the GHN.

The main control class is the org.gcube.security.soa3.connector.integration.server.SOA3IntegrationSecurityController which 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 the org.gcube.security.soa3.connector.SOA3SecurityController class, which actually executes the checks. The library also assure compatibility between the GSS stack used in Globus based GHN and the common-security library.

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.