- 1 Main Security Library
- 2 Extension Security Libraries
- 3 Security Plugins
Main Security Library
The Security Library is the main plugin library of gCube Security Infrastructure. It provides the classes implementing the security behaviour inside the trusted infrastructure. In particular it implements Role Based Access Control, Interaction with Argus and, more in general, interaction with any XACML based Authorization Service. It also implements the classes that add the security information in an outgoing message directed to the Trusted Network: in particular some classes adding a SAML Assertion containing the caller role are provided.
The security features implemented are based on the following interfaces of the gCore Framework:
- GCUBESecurityManager (outgoing messages security management)
- GCUBESecurityAuthenticationController (incoming messages authentication control)
- GCUBESecurityAuthorizationController (incoming messages authorization control)
The first one manages outgoing messages adding security related information, the other ones perform authentication and authorization control for incoming messages. Security controls are performed by the called GHN for the called Running Instances: outgoing messages security management could be performed by a GHN in server mode (when a Running Instance calls another Running instance) or by a client. For this reason GCUBESecurityManager has two children interfaces:
- GCUBEClientSecurityManager when the GHN is running in client mode
- GCUBEServiceSecurityManager for services
Basic implementatations provided
GCore framework provides some basic implementations for some of the interfaces described, in particular:
- GCUBESimpleServiceSecurityManager, which implements GCUBEServiceSecurityManager and does nothing as it forces to disable security
- GCUBESimpleServiceAuthController, which does nothing and is used when authentication is managed by other components
- GCUBEAuthzChainAuthorizationController which implements GCUBESecurityAuthorizationController using some internal API in order to implement an Authorization Chain. An Authorization Chain is a chain of operation called by the infrastructure to check authorization rights: in particular the operation could be Policy Information Point (PIP) operation and Policy Decision Point (PDP) operations. The former ones collect authorization related information and the latter ones check the privileges.
SAML Assertion Security Managers
The module provides two SAML Assertion based Security Managers:
- GCUBESamlAssertionServiceSecurityManager, used inside a service
- GCUBESamlAssertionAutoInsertClientSecurityManager, used in client mode
Both the Security Managers add a SAML Assertion in the outgoing message and configure it to be signed by GHN host certificate and, if required, be encrypted. The SAML Assertion Client security manager generates on-the-fly an assertion containing the identity specified in configuration and adds it directly inside the SOAP message. The SAML Assertion Service Security Manager provides the option to use caller credential or service credential. In the first case, the caller SAML Assertion is used as identity of the outgoing message (delegation): if no assertion exists the service credential are used. The service credentials is a particular assertion with lifetime of 8 hours generated by a scheduled process every 4 hours with the identity of the service. Service identity is a string composed of the following format: <ServiceClass>:<ServiceName>.
SAML Assertion Security Managers configuration
The GHN security status is set on GHNConfig.xml file by the option securityenabled (for client mode GHNConfig.client.xml is used). The same option is available in the service jndi file to provide service-specific behaviors. The default GHN Service Security Manager is set in implementations.properties file as implementation of the class GCUBEServiceSecurityManager. It is possible to set a service-specific security manager in service-jndi file by the option securityManagerClass. The default security options are set in default services security configuration file, whose link is in the server-wsdd file as defaultSecurityConfiguration option. Default services security configuration is an xml file in which it is possible to set:
- security protocol (GSITransport = https) or GSISecureConversation
- protection level (integrity = signature, privacy)
- credential propagation (enabled means that caller credential will be used, not enabled means that service credential will be used)
Service-specific behaviors can be set using outgoing messages security descriptors, in the stubs of the called service, where it is possible to set the security protocol and the protection level, and in service-jndi where, by the option propagateCallerCredentials
Simple Authentication Controller
This component does nothing, because the https authentication is performed by internal API.
Authorization Chain Security Controller
The only Security Controller used for trusted network security is the Authorization Chain based one. The Authorization Chain is composed by a PIP, XACMLServiceNameBasedPIP (org.gcube.common.vomanagement.security.authorisation.control.impl.xacml.XACMLServiceNameBasedPIP), and a PDP, XACMLBasedPDP (org.gcube.common.vomanagement.security.authorisation.control.impl.xacml.XACMLBasedPDP): both the classes are shipped in the org.gcube.common.vomanagement.security.jar. The former collects service information, operation information and role information, the latter asks an Authorization Service or an authorization response's internal cache
Authorization Chain configuration
For the Authorization Chain configuration the security descriptors and the wsdd files are used. In particular global configuration is set on global security descriptor and on server-wsdd file, service based configuration on service security descriptor and on service wsdd file. In the security descriptor, the element authz contains the classes of the Authorization Chain, in the following format:
<authz value="identifier:pip_class identifier:pdp_class"/>
The identifier is used to mark the configuration options that are set in the wsdd file (of the server or of the service), in this way:
<parameter name="identifier-param_name" value="param_value"/>
So, the identifier is useful to match the configuration to the correct chain.
The Classes used in the Authorization Chain for our trusted network need only one parameter: authzXACMLServiceUrl, that is the Endpoint where the authorization requests are sent.
Extension Security Libraries
In order to enable interoperability with external infrastructures two extension packages are provided:
- Portal Based Security Controller Library, to perform controls based on the DN of incoming messages
- VOMS Security Library, useful to provide VOMS credentials based on user, host o robot certificates
The first package contains the class IncomingMessageEdgeServiceDNAuthorizationController, which implements an authorization controller based on the DN of the caller. The DN is retrieved from the signature of the message in HTTPS: the information is used to ask the portal for the credentials of the caller. In particular, by the User Management Web Service, the Controller tries to obtain the user id and the roles, available if the DN is associated to a registered user. If this information is obtained, it is used to check the authorization privileges by the Authorization Chain and a SAML Assertion is generated if the roles should be propagated inside the infrastructure.
The configuration is the same of Authorization Chain case, with the only add of the URL of the Identity Service (identityServiceUrl), which is the User Management Web Service. This information is added in the GHNConfig.xml file or, if service based, in the service jndi.
The VOMS Security Library contains the class VOMSServiceCredentialsSecurityManager, which contacts a VOMS Server in order to obtain a VOMS certificate starting from a certificate stored in the local machine. The Security Manager could be assocated to a Service if gCube compliant calls are needed, or could be used only to retrieve the certificate for customized behaviors.
The parameters to be set (in GHNConfig.xml or service jndi) are the following:
- VomsServer, URL of the VOMS server
- vomsAdminPort, the admin port of the VOMS Server
- vomsServicePort, the service port of the VOMS Server
- vomsServiceDN, the DN of the VOMS Server
- VoName, the name of the Virtual Organization
- ServiceKey, the certificate private key
- ServiceCert, the certificate public key
- ServiceKeyPwd, the password of the private key if required
In no certificate is set, the host certificate is used.
All the security plugins and the specific configuration steps are described in the section Security Plugins Table.