Difference between revisions of "GCube Security Configuration"

Revision as of 17:57, 11 March 2013

A Secure GHN provides two security levels:

• transport level
• message level

Each level concerns both incoming and outgoing messages: in the former case we talk about security controls, in the latter credential management. This page will provide a quick explanation about the concepts above, and a description on 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 or no-sec). 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

GHN secure distribution can be started in secure mode configuring the container with the usual steps. In this section the configuration options will be described in order to provide the possibility to define security level more suitable to the use cases.

Message level security is enabled or disabled in the files:

• GHNConfig.xml (for incoming messages)
• GHNConfig.client.xml (for outgoing messages)

both the files are in the folder GLOBUS_LOCATION/config and the parameter is securityenabled, which is true by default in the secure distribution. Security should be enable also for outgoing messages because container commands (e.g. shutdown), should be sent in HTTPS if the container runs in TLS mode: by enabling client security we can use container built-in clients in HTTPS.

In the folder GLOBUS_LOCATION/etc/globus_wsrf_core, the file server-config.wsdd contains two elements:

• <parameter name="defaultSecurityConfiguration" value="etc/globus_wsrf_core/security_configuration.properties"/>
• <parameter name="containerSecDesc" value="etc/globus_wsrf_core/global_security_descriptor.xml"/>

The first one points to container security configuration file, the second one to container security descriptor.

Container Security Configuration File defines the message level security features at container level, in particular:

• SERVER_URL SOA3 connector service url (e.g. http://192.168.125.249:8080/soa3Service)
• CREDENTIAL_PROPAGATION_POLICY defines if the credentials should be propagated as ticket
• SECURITY_ENABLED optional: if defined overrides the securityenabled property set in GHNConfig.xml

This configuration can be set per-service, using the optional file:

GLOBUS_LOCATION/etc/<serviceName>/serviceSecurityProperties.props

This file contains the same properties of the previous one.

Container security descriptor file defines the path of container cert and key for TLS:

   <credential>
       <key-file value="/etc/grid-security/containerkey.pem"/>
       <cert-file value="/etc/grid-security/containercert.pem"/>
   </credential>

If the two elements don't point to valid key and cert, the container started in TLS mode fails. Anyway the certificates are also used as default TLS credentials for outgoing messages.

The container can be started in no-sec mode or TLS mode: it depends on the script used to start it.

• gcore-start-container starts the container in no-sec mode (all the services are listening for HTTP requests)
• gcore-start-secure-container starts the container in TLS mode (all the services are listening for HTTPS requests)

It is not recommended to use Message Level Security and start the container in no-sec mode: in this way the credentials will be sent unencrypted.