Difference between revisions of "GCube Credentials"

From Gcube Wiki
Jump to: navigation, search
(Created page with '==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 …')
 
(Username/Password)
Line 21: Line 21:
  
 
===Username/Password===
 
===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.
+
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 (Base64 encoded): 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====
 
====Username/Password and Common Security====
Line 30: Line 30:
 
  Base64EncodedCredentials encodedCredentials = new Base64EncodedCredentials(pureCredentials); //Base64 encodes the credentials
 
  Base64EncodedCredentials encodedCredentials = new Base64EncodedCredentials(pureCredentials); //Base64 encodes the credentials
 
  CredentialManager.instance.set(encodedCredentials); //sets the credentials in the Credential Manager
 
  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
+
 
 +
===Assertion ID===
 +
After a successfull authentication on a federated domain, SOA3 produces an ''Assertion ID'', identifying a SAML Assertion. The Assertion ID can replace Username/Password information in the header of the SOAP Message (in HTTPS). The authentication process on the Nodes is similar to Username/Password case: the Node receives the request and send the Assertion ID to SOA3 Server. SOA3 retrieves the Assertion, validates it and gets the attributes which are used for the authorization. If everything is OK a ticket is returned.
 +
 
 +
====Assertion ID and Common Security====
 +
 
 +
The following piece of code shows how to set Assertion ID credentials in a gCube client and encode them in Base 64.
 +
 
 +
FederatedCredentials pureFederatedCredentials = new FederatedCredentials("AssertionID");
 +
Base64EncodedCredentials encodedCredentials = new Base64EncodedCredentials(pureFederatedCredentials); //Base64 encodes the credentials
 +
CredentialManager.instance.set(encodedCredentials); //sets the credentials in the Credential Manager
 +
 
 +
 
 +
===X509 Certificate===
 +
X509 Certificates are used to sign and encrypt messages sent on HTTPS (Transport Level Security). In this case the security is implemented on a level lower than Message Level Security: this means that there is the possibility (and it is strongly encouraged) to use the combination of both TLS and MLS. For enabling HTTPS communications, gCube Nodes should be started in https mode, by using the script:
 +
 
 +
gcore-start-secure-container   
 +
 
 +
No other configuration is required: if MLS is enabled every Node will combine Username/Password, Assertion ID or Tickets with HTTPS, otherwise only HTTPS will be used.
 +
 
 +
===X509 Certificate and Common Security===
 +
 
 +
At client level, it is possible to enable https by using java standard security options or Common Security library. Java provides the possibility to use a ''keystore'' and a ''truststore'', set through java properties:
 +
 
 +
javax.net.ssl.keystore
 +
javax.net.ssl.truststore
 +
 
 +
Common Security library provides a method more consistent with the rest of SOA3 Framework. In particular, the following piece of code sets X509 key and certificate (''pem'' format) and the truststore directory:
 +
 
 +
X509TLSCredentials tlsCredentials = new X509TLSCredentials("certFilePath","keyFilePath","trustStoreDirPath","trustFilesExtension");
 +
CredentialManager.instance.set(tlsCredentials); //sets the credentials in the Credential Manager
 +
 
 +
All the files must be in ''pem'' format and the key must be RSA encoded. The trust store directory must contain CA certificates in ''pem'' format with the extension of "trustFilesExtension".
 +
The fields are not mandatory and the default values are the following:
 +
 
 +
* certificate <code>/etc/grid-security/hostcert.pem</code>
 +
* key <code>/etc/grid-security/hostkey.pem</code>
 +
* trust directory <code>/etc/grid-security/certificates</code>
 +
* extension <code>.0</code>

Revision as of 12:52, 3 December 2013

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 (Base64 encoded): 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

Assertion ID

After a successfull authentication on a federated domain, SOA3 produces an Assertion ID, identifying a SAML Assertion. The Assertion ID can replace Username/Password information in the header of the SOAP Message (in HTTPS). The authentication process on the Nodes is similar to Username/Password case: the Node receives the request and send the Assertion ID to SOA3 Server. SOA3 retrieves the Assertion, validates it and gets the attributes which are used for the authorization. If everything is OK a ticket is returned.

Assertion ID and Common Security

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

FederatedCredentials pureFederatedCredentials = new FederatedCredentials("AssertionID");
Base64EncodedCredentials encodedCredentials = new Base64EncodedCredentials(pureFederatedCredentials); //Base64 encodes the credentials
CredentialManager.instance.set(encodedCredentials); //sets the credentials in the Credential Manager


X509 Certificate

X509 Certificates are used to sign and encrypt messages sent on HTTPS (Transport Level Security). In this case the security is implemented on a level lower than Message Level Security: this means that there is the possibility (and it is strongly encouraged) to use the combination of both TLS and MLS. For enabling HTTPS communications, gCube Nodes should be started in https mode, by using the script:

gcore-start-secure-container    

No other configuration is required: if MLS is enabled every Node will combine Username/Password, Assertion ID or Tickets with HTTPS, otherwise only HTTPS will be used.

X509 Certificate and Common Security

At client level, it is possible to enable https by using java standard security options or Common Security library. Java provides the possibility to use a keystore and a truststore, set through java properties:

javax.net.ssl.keystore
javax.net.ssl.truststore

Common Security library provides a method more consistent with the rest of SOA3 Framework. In particular, the following piece of code sets X509 key and certificate (pem format) and the truststore directory:

X509TLSCredentials tlsCredentials = new X509TLSCredentials("certFilePath","keyFilePath","trustStoreDirPath","trustFilesExtension");
CredentialManager.instance.set(tlsCredentials); //sets the credentials in the Credential Manager

All the files must be in pem format and the key must be RSA encoded. The trust store directory must contain CA certificates in pem format with the extension of "trustFilesExtension". The fields are not mandatory and the default values are the following:

  • certificate /etc/grid-security/hostcert.pem
  • key /etc/grid-security/hostkey.pem
  • trust directory /etc/grid-security/certificates
  • extension .0