Difference between revisions of "GHN Security Configuration"

From Gcube Wiki
Jump to: navigation, search
(Created page with '==Introduction== The secure distribution bundle of gCube contains the libraries and the base configurations to set the internal infrastructure security, that is based on Transpor…')
 
Line 145: Line 145:
  
 
In the most of cases the clients, in secure mode, needs an identity parameter: it will be used to configure on the fly the Security Manager. So, if a client should be designed, a secure running mode should be planned: this running mode should perform calls in https and should use a security manager (loaded from implementation.properties, or, better, by the call <source lang="java"> SecurityContextFactory.getInstance().getSecurityContext().getDefaultSecurityManager() </source> of the SecurityContextFactory provided in gCore framework. The Security Manager should be configured by an identity loaded from startup parameters or provided by the client.
 
In the most of cases the clients, in secure mode, needs an identity parameter: it will be used to configure on the fly the Security Manager. So, if a client should be designed, a secure running mode should be planned: this running mode should perform calls in https and should use a security manager (loaded from implementation.properties, or, better, by the call <source lang="java"> SecurityContextFactory.getInstance().getSecurityContext().getDefaultSecurityManager() </source> of the SecurityContextFactory provided in gCore framework. The Security Manager should be configured by an identity loaded from startup parameters or provided by the client.
 +
 +
[[Category:Security]]

Revision as of 14:04, 29 July 2011

Introduction

The secure distribution bundle of gCube 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:

  • the first one provides a list and a brief description of the files used for security configuration
  • the second one provides an overview of the security configuration provided in the secure GHN distribution
  • the third one provides information about the settings to be used to face different situations (i.e. interoperability)
  • the forth one describes the client mode configuration

Security configuration files

The most of the files used for the security configurations are not new in the container: only more information are provided. The only extra file is the Default Security Configuration. For the global security configuration these files are used:

  • GHNConfig.xml (and GHNConfig.client.xml), in config directory: contains the security status (enabled or disabled) and some global special purpose information related to the security manager chosen (see Security Plugins Table section)
  • implementation.properties, in config directory: contains the global Service Security Manager, Client Security Manager, Authentication and Authorization Controller
  • server-config.wsdd, in the directory /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 behavior

Per service security configuration uses the following files:

  • Service jndi-config.xml", in the /etc/sevice directory: contains the security status for the service (enabled or disabled), the propagation credential status and other special purpose information related to the security manager chosen (see Security Plugins Table section)
  • service.wsdd, in the /etc/sevice directory: contains the link to the local incoming message security descriptor and other special purpose information (if required)
  • Incoming Messages Security Descriptor: contains information about the security protocol used and the security level (if different from the global configuration)
  • 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 a security descriptor parameter: the security descriptor is considered only if the parameter in the wsdd is correctly set.

There are also two command files, in the bin directory: gcore-start-secure-container.sh and gcore-stop-secure-container, that start and stop the container with TLS support.

Security Configuration provided

In order to obtain TLS Authentication and SAML Authorization as global behaviour, the global 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 a (not working) Authorization Provider: it should 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 path of the host certificate is 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 behavior is 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 sets if the configuration should be read by the system: if the attribute is false 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 (if the admin wants that only service credentials should 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 for the related service
  • the authenticationManagerClass: the class of the authentication manager used only for the related service
  • the authorisationManagerClass: the class of the authorization manager used only for 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 bahaviors, 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>
it configures TLS with encryption for the method about: to configure the security features for all the methods the
 <auth-method>
element should be placed out of the
 <method>
element.

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 tell to 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.

Client configuration

A Client Security Manager needs only a parameter that indicates the identity of the user who performs the call: what the Identity Parameter is, in concrete cases, depends from the implementation of the security manager and is described in the Security Plugins Table section. However, for the clients, the binding with the Security Manager is dynamic and is performed setting the field GCUBEClientSecurityManager in implementation.properties file, for example, in the default security bundle, the configuration is the following:

GCUBEClientSecurityManager = org.gcube.common.vomanagement.security.configuration.client.GCUBESamlAssertionAutoInsertClientSecurityManager

and means that a SAML Assertion Security Manager will be used for clients.

In the most of cases the clients, in secure mode, needs an identity parameter: it will be used to configure on the fly the Security Manager. So, if a client should be designed, a secure running mode should be planned: this running mode should perform calls in https and should use a security manager (loaded from implementation.properties, or, better, by the call
 SecurityContextFactory.getInstance().getSecurityContext().getDefaultSecurityManager()
of the SecurityContextFactory provided in gCore framework. The Security Manager should be configured by an identity loaded from startup parameters or provided by the client.