GHN Security Configuration
The GHN secure distribution bundle contains the libraries and the base configurations to set the internal infrastructure security, that is based on Transport Level Security for Authentication and SAML Assertions for Authorization. This section is composed by four parts:
- a list and a brief description of the security configuration files
- an overview of the security configuration provided in the secure GHN distribution
- information about the settings to be used to face different situations (i.e. interoperability)
- description of the client mode configuration
Security configuration files
Most of the files used for the security configurations are already provided by the ws-core container: only more information is provided. The only extra file is the Default Service Security Configuration (default_services_security_configuration in /etc/globus_wsrf_core directory). For the global security configuration these files are used:
- GHNConfig.xml (and GHNConfig.client.xml), in $GLOBUS_LOCATION/config directory: contains the security status (enabled or disabled). It is also used to set some extra settings related to the choosen Security Manager or Security Controller: in this case this information has GHN scope. For example the VOMSServiceCredentialsSecurityManager needs the VOMS service url or the VO name: these parameters can be placed in the GHNConfig.xml file. To have a complete list of these parameters see Security Plugins Table section
- implementation.properties, in $GLOBUS_LOCATION/config directory: defines the global Service Security Manager, Client Security Manager, Authentication and Authorization Controller implementations
- server-config.wsdd, in the directory $GLOBUS_LOCATION/etc/globus_wsrf_core: contains the link to the Global Security Descriptor and the Default Services Security Configuration; it also contains other special purpose information
- Global Security Descriptor: contains the link to the container certificate and the definition of the authorization chain (if exists)
- Default Services Security Configuration: contains information about the security protocol used and the security level; it also contains information about the credential propagation behaviour
Per service security configuration uses the following files:
- Service jndi-config.xml", in the $GLOBUS_LOCATION/etc/<service> directory: contains the security status for the service (enabled or disabled), the propagation credential status. It can contain the extra settings described in the GHNConfig.xml bullet: in this case the scope is the specific service
- server-config.wsdd, in the $GLOBUS_LOCATION/etc/<service> directory: contains the link to the local Incoming Message Security Descriptor, set in the element securityDescriptor (see the next point) and other settings related to the web service (if required)
- Incoming Messages Security Descriptor: contains information about the security protocol used and the security level (if different from the global configuration). Its path is set in the server-config.wsdd (see the point above).
- Outgoing Messages Security Descriptor, in the jar of the stubs of the called service: contains information about the security protocol used and the security level to be used to call the related service if different from global configuration. In the stubs there is also a deployment descriptor (wsdd) with an element called securityDescriptor: this elements contains the name of the Outgoing Messages Security Descriptor file in the stub.
There are also two commands, in the $GLOBUS_LOCATION/bin directory: gcore-start-secure-container.sh and gcore-stop-secure-container, needed to start and stop the container with TLS support.
Security Configuration provided
In order to obtain TLS Authentication and SAML Authorization as global behaviour, the configuration is the following.
- both the files GHNConfig.xml and GHCConfig.client.xml file contain the parameter securityenabled set to true
- the implementation.properties file contains the fields:
GCUBEServiceSecurityManager = org.gcube.common.vomanagement.security.configuration.GCUBESamlAssertionServiceSecurityManager GCUBEServiceAuthenticationController = org.gcube.common.core.security.impl.GCUBESimpleServiceAuthController GCUBEServiceAuthorizationController = org.gcube.common.core.security.impl.GCUBEAuthzChainAuthorizationController
further information about the meaning of this security manager and the auth and authz controller are in Security Plugins Table section
- the server-config.wsdd file contains the following parameters
<parameter name="containerSecDesc" value="etc/globus_wsrf_core/global_security_descriptor.xml"/> <parameter name="defaultSecurityConfiguration" value="etc/globus_wsrf_core/default_services_security_configuration.xml"/> <parameter name="pip-authzXACMLServiceUrl" value="https://grids03.eng.it:8152/authz"/>
the first parameter sets the relative path of the global security descriptor, the second one sets the path of the default services security configuration and the third one is the url of an Authorization Provider (to be replaced with the correct url).
- The Global Security Descriptor is the following:
<securityConfig xmlns="http://www.globus.org"> <credential> <key-file value="/etc/grid-security/containerkey.pem"/> <cert-file value="/etc/grid-security/containercert.pem"/> </credential> <authz value="pip:org.gcube.common.vomanagement.security.authorisation.control.impl.xacml.XACMLServiceNameBasedPIP pip:org.gcube.common.vomanagement.security.authorisation.control.impl.xacml.XACMLBasedPDP"/> </securityConfig>
where the paths to the host certificate cert/key are set and the Authorization Chain is defined Authorization Chain configuration
- The Default Service Security Configuration is the following:
<services_security xmlns="http://www.d4science.eu"> <in enabled="true" override="false"> <auth_method>GSITransport</auth_method> <protection_level>integrity,privacy</protection_level> </in> <out enabled="true" override="true"> <auth_method>GSITransport</auth_method> <protection_level>integrity,privacy</protection_level> </out> <propagateCallerCredentials override="false" value="true"/> </services_security>
where the incoming and outgoing messages behaviours are defined. In particular the security protocol is GSITransport (TLS), the protection level is integrity (digital signature) and privacy (encryption) and the caller credential propagation is enabled. The enable attribute on in and out specifies if the configuration should be read by the system: if the attribute is set to false the service based configuration became mandatory. The override attribute, if set to true forces the system to adopt the global configuration even if a per service configuration exists.
It is possible to change the global security configuration to satisfy some extra requirements, but the most usual changes to be performed could be:
- the security status (enabled or disabled)
- the path of the host certificate
- the url of the Authorization Service
- the protection level (only signature improves the performances)
- the credential propagation status (to force only service credentials to be used)
The truststore of a GHN is in the folder: /etc/grid-security/certificates. This folder should contain the trusted CA certificates and the updated revocation list stored in files named with the CA hash, for example:
- 2f3fadf6.0 is a certificate
- 2f3fadf6.r0 is the revocation list
- 2f3fadf6.namespace, 2f3fadf6.info, 2f3fadf6.crl_url, 2f3fadf6.signing_policy contain other information
Per Service settings
The Service jndi-config.xml contains the following parameters:
- the security status securityenabled (boolean)
- the securityManagerClass: the class of the security manager used only by the related service
- the authenticationManagerClass: the class of the authentication manager used only by the related service
- the authorisationManagerClass: the class of the authorization manager used only by the related service
The parameters are not mandatory, and, if not present, the global parameters are used. By the local configuration it is possible to define some per service behaviours, useful for services that should interact with external infrastructures. For these kind of Edge Services the most used security managers and controllers are described in the section Extension Security Libraries. Other possible choices are in the Security Plugins Table section, where the further configuration parameters needed are also described.
An example of Service Security Descriptor is the following:
<method name="about"> <auth-method> <GSITransport> <protection-level> <privacy/> </protection-level> </GSITransport> </auth-method> </method>
The service.wsdd file should point to the local security descriptor with an element like the following:
<parameter name="securityDescriptor" value="etc/org.acme.sample/security_descriptor.xml"/>
in order to instrument the server to read the local security descriptor, otherwise the default security configuration is used. For outgoing messages configuration the concept is similar, with the difference that, inside the wsdd internal to the stub jar, the parameter should point to the name of the security descriptor file in the jar, the path is not required.
A secure client, in general, uses https as communication protocol and a Security Manager. The Security Manager could be the default one, loaded from implementation.properties:
GCUBEClientSecurityManager = org.gcube.common.vomanagement.security.configuration.client.GCUBESamlAssertionAutoInsertClientSecurityManager
The Identity Parameter is not valid for the authentication (for this purpose only the host certificate is used), but it determines only the authorization privileges basing on the identity of the user who performs the call: what the Identity Parameter is, in concrete cases, depends on the implementation of the security manager and is described in the Security Plugins Table section.
In our infrastructure the Role or the Service ID (serviceClass.serviceName) should be used as Identity Parameter. The clients should provide the parameter to the Client Security Manager by the method
if more than a single Identity is needed.
The way used by the client to obtain this information from the user depends on the client implementation: for example the clients used only by Infrastructure Administrators, that are placed on a trusted GHN, don't use any identity parameter (in particular their Identity is the DN of the caller host) or requires it as command line parameter.