Difference between revisions of "GCube Security Configuration"

Revision as of 17:56, 27 January 2014

Overview

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 a certain security level.

Security Controls

Transport Level

Transport level security (TLS) concerns the signature and the encryption at transport level obtained by X509 Certificates and HTTPS protocol. The container performs the control on client certificates using a default Trust Store containing trusted CA certificates and revocation lists. The default trust store is defined by GSS API in /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 details 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 checks by default client certificates of all the requests. Currently it is not possible to define any per-service policy for this feature.

Message Level

Message level security controls are performed on certain pieces of information in the Security Header of SOAP Messages. The sementic of these pieces of information defines three authentication factors:

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

GHNs support all these factors: the first two are based on the Security Header and are mutially exclusive. In particular the Security Header is compliant to WS-Security 1.1 Specification. The Security Header contains a BinaryToken element:

  <wsse:BinarySecurityToken wsu:Id="SecurityToken" EncodingType="Base64" ValueType=<type>>
              Base64Data
  </wsse:BinarySecurityToken>

where type currently can be BASIC (for username/password authentication) or FED (for Federated Authentication). If any security information is found at message level, the GHN tries to perform TLS Certificate authentication as a last resort.

If the authentication is grant, SOA3 Security System sends a ticket to be used if the request must be propagated to another GHN with the same identity. The ticket is used as message level authentication information in the header (of type SES, Session) of the propagated SOAP message and will be checked by the next node of the chain 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 latter case is described in GCube Clients Integration with security, the former 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

A GHN built as secure distribution can be started in TLS mode without any special configuration step.

Anyway, in order to enable Message Level Security, or define a non default location for the certificates, some extra configuration steps are needed. In this section a description of the security configuration options is provided.

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 in form of 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.