GCube Security Configuration

From Gcube Wiki
Revision as of 14:21, 7 March 2013 by Ciro.formisano (Talk | contribs) (Created page with 'A GHN provides two security levels: * transport level * message level Each level must be considered for incoming messaged and outgoing messages: in other words, security contro…')

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

A GHN provides two security levels:

  • transport level
  • message level

Each level must be considered for incoming messaged and outgoing messages: in other words, security controls and credential management. This page will provide a quick explanation about the differences among the four combinations of the concepts above, and how to configure the container to obtain the desired security level.

Security Controls

Transport Level

The controls on TLS (Transport Level Security) of received messages are managed at container level: this means that the container defines a default trust store containing trusted CA certificates and revocation lists. The default trust store is defined by GSS API and is /etc/grid-security/certificates: the files are in PEM format and are named with the hash of the CA (to obtain this hash value openssl x509 -in certname.pem -issuer_hash), with extension .0 (for CA certificates) or .r0 (for revocation lists). For further explanation please, refer to GSS documentation.

If a secure container is started using the script:

gcore-start-secure-container.sh

it will run in TLS mode: this means that all the services will be listening for HTTPS requests. A container in TLS mode makes the checks on client certificates by default on all the requests. Currently there isn't any per-service policy available for this feature.

Message Level

Message level security controls are performed on certain information to be sent in the Security Header of SOAP Messages. GCube currently supports three kind of authentication:

  • Username/password, based on u/p basic authentication
  • Federated, based on SAML federation
  • TLS Certificate, based on the DN of the certificate received at Transport Level (if TLS is enabled)

The third check is performed as last resort if and only if nosecurity information is found in the SOAP message. If the authentication is grant, SOA3 Security System sends a ticket that can be found if the request must be propagated to another node with the same identity. The ticket is used as message level authentication information in the header of the propagated SOAP message and will be checked by the next node of the chainm avoiding actual credential propagation. The ticket defines a session whose duration is configured on SOA3.

Credential Management

Transport Level

Outgoing messages can be sent in HTTP or HTTPS regardless the running mode of the container (TLS od unsecure). If HTTPS messages need to be sent, the container should be configured to load public and private keys. The container will use configured keys by default: it is also possible to define per-service behavior using client Credential Manager (look at GCube Clients Integration with security).

Message Level

Message level security information can be propagated or defined by the service. The former case is described in GCube Clients Integration with security, the first case is the default behavior. In particular the identity propagation can be enabled or disabled at container or service level: if the identity propagation is enabled, the ticket received by SOA3 is inserted in the outgoing message, otherwise the container does't add any message level authentication information, delegating this task to the service, as descrived above, or using only TLS.

Security Configuration