GCube Credentials

Overview

SOA3 Framework provides the API to manage several kinds of credentials. GCube Nodes communicate each other by propagating the identity of the original caller usung a reference ticket. The original caller, that can be an user or a process (i.e. a service) can be identified by the following credentials:

• Username/Passrword, used especially by human callers
• SAML Assertion Id, for federated authentication
• X509 Certificate, used by human callers or by batch processes (i.e. services that needs authonomous authentication)

This section will briefly describe the supported credentials and show how Client Security Library provides the possibility to use those credentials.

Credentials

SOA3 authenticates and authorizes requests basing on the credentials of the caller: no explicit distinction between Message Level Security and Transport Level Security is done. However the integration layer combines TLS and MLS in the following way:

1. each node checks authonomously the TLS signature of the HTTPS received message: if it is not valid, the process is interrupted and an unauthorized error is returned

2. the node checks if any Message Level Credential is present in the received SOAP message. If it is found, is sent to SOA3 that checks its validity: if it is valid, the message is authenticated, if it is not valid, an error is returned, if it is not found, the process goes to the point 3

3. the node extracts the DN of the certificate used to sign the HTTPS request and sends it to SOA3

The communications between the Nodes and SOA3 are in HTTPS and the information is send by REST messages. The Message Level Credentials are send by the client of the caller to the Nodes in the security header of SOAP messages: the Portal, which contacts the service by ASL, works in the same way. The Common Security library adds the credentials to all the requests.

Username/Password

SOA3 Framework supports common Username/Password authentication. Username and Password are set in the security header of the SOAP Message and currently are send in clear text: this means that HTTPS must be used to encrypt the communication and the credentials. When a GCube Node receives Username/Password credentials, it sends a REST Access Request to SOA3: if the Access Request (authentication and authorization) succeeds, a ticket is returned. This ticket will replace the credentials if they needs to be propagated in gCube infrastrucure.

Username/Password and Common Security

The following piece of code shows how to set Username/Password credentials in a gCube client and encode them in Base 64.

UserNamePasswordCredentials pureCredentials = new UserNamePasswordCredentials("gCube", "gCube".toCharArray());
Base64EncodedCredentials encodedCredentials = new Base64EncodedCredentials(pureCredentials); //Base64 encodes the credentials
CredentialManager.instance.set(encodedCredentials); //sets the credentials in the Credential Manager
stub = stubFor(stateless).at(URI.create("http://localhost:9999/wsrf/services/acme/sample/stateless")); // creates the stub