Difference between revisions of "GHN Security Configuration"
Andrea.manzi (Talk | contribs) (→Introduction) |
Andrea.manzi (Talk | contribs) (→Security configuration files) |
||
Line 8: | Line 8: | ||
==Security configuration files== | ==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 Security Configuration'''. | |
For the global security configuration these files are used: | 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) | + | * ''GHNConfig.xml'' (and ''GHNConfig.client.xml''), in $GLOBUS_LOCATION/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: | + | * ''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 /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 | + | * ''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) | * ''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 | + | * ''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: | Per service security configuration uses the following files: | ||
− | * ''Service jndi-config.xml", in the /etc/ | + | * ''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 and other special purpose information related to the security manager chosen (see [[Security Plugins Table]] section) |
− | * ''service.wsdd'', in the /etc/ | + | * ''service.wsdd'', in the $GLOBUS_LOCATION/etc/<service> 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) | * ''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. | * '' 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 | + | 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== | ==Security Configuration provided== |
Revision as of 10:52, 29 August 2011
Contents
Introduction
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 Security Configuration. 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) and some global special purpose information related to the security manager chosen (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 and other special purpose information related to the security manager chosen (see Security Plugins Table section)
- service.wsdd, in the $GLOBUS_LOCATION/etc/<service> 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 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 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>
<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 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 callSecurityContextFactory.getInstance().getSecurityContext().getDefaultSecurityManager()