Difference between revisions of "How To Configure Service Security"

Revision as of 14:38, 20 May 2009

THIS SECTION OF GCUBE DOCUMENTATION IS OBSOLETE. THE NEW VERSION IS UNDER CONSTRUCTION.

This page contains useful information for gCube service configuration to be compliant with the GCUBE Security Model.

Configure service authentication

This configuration protects the service against unauthenticated access, setting it each client is forced to present valid credentials. Please notice that with these settings authorization is still not enforced on the service. This means that every authenticated client is entitled to use service operations.

Create Web Service Security Descriptor (WSSD)

Create the Web Service Security Descriptor. A different security descriptor file should be created for each interface of your service in the etc/ directory of your service. See Media:YourService-security-config-1.xml for an example.

For detailed information about security options supported in security desciptors you can take a look at the ws-core documentation here

In the security descriptor configuration you should avoid to specify credentials for your service. Credentials for DILIGENT services can be obtained through the Delegation service developed in the DVOS class. For detailed information about how to provides your services with credentials you can refer to the How_To_Configure_Service_Security#Provide_your_service_with_credentials section of this page.

The gridmap file setting should also be avoided, authorization for DILIGENT services is enforced using the DVOS Authorization Service. It can be configured as explained in the [[1]] section.

Currently the only Authentication method supported in the DILIGENT infrastructure is the GSISecureConversation one, both with or without privacy or integrity options.

The run-as identity should be limited to service-identity or caller-identity, depending on which credentials are used by your service to perform invocations.

Modify Web Service Deployment Descriptor (WSDD)

Modify the Web Service Deployment Descriptor to refer the Web Service Security Descriptor. Add following line to the service tag:

<parameter name="securityDescriptor" value="@config.dir@/YourService-security-config.xml"/> 

(of course the value must be set to the name of the WSSD you just created) See Media:deploy-server-1.wsdd for an example

Then redeploy your service in the DHN container.

Access a service using authentication

In this step you'll try to access your service with a client using authentication. This step assumes the service has been deployed in a container able to host secure services. The How To Configure gContainer Security page describes steps needed to set-up a secured gContainer.

First of all try to contact your service using an unauthenticated client, you should get following Axis fault:

... GSI Secure Conversation authentication required for
"{http://yournamespaces/namespaces/..." operation.

This means that the GSI Secure Conversation mechanism is required to invoke the service. To enable it, follow those steps.

Set credentials on service stubs

PortType PT = new ServiceAddressingLocator().gePortTypePort(epr);
//  PORTTYPE getProxy(PORTTYPE portTypeStub, GCUBEScopeManager scopeManager, GCUBESecurityManager ... securityManager)‏
PT = GCUBERemotePortTypeContext.getProxy(PT, scopeManager, serviceContext);

Don't forget to add the client-config.wsdd file in the directory where you run the client. Alternatively, you can add the $GLOBUS_LOCATION as the first entry of your classpath. Then you should be able to contact your service using your credentials.

Provide your service with credentials

After the previous steps, your service can authenticate itself in outcoming requests towards other services. To provide credentials to your service you have to configure the jndi file of your service. This allows your service to interact with the co-hosted instance of gCube Delegation service and a gCube CredentialsRenewal service available in your service's scope (as described in following section)

Which kind of security needs your service? Understand the semantic of your service

Typically a GCUBEService can be of three types:

1. Doesn't need credentials but runs in a secure infra
2. Acts on behalf of a caller
3. Autonomous and needs service credentials

The gCF introduces the concept of SecurityManager to manage those scenarios and simplify security aspects management. Security managers keep track of credentials to use for outgoing calls in one or more concurrent threads. a client which obtains credentials hands them over to the manager where may later find them. Security managers are transparent in an insecure context Implementations of the interfaces above ought to implement the method isSecurityEnabled() to discriminate secure from insecure contexts.

GCF provides a basic and an advanced implementation of the SecurityManager interface that cover the three most common scenarios described before Moreover the ServiceContext is a wrapper of the SecurityManager

SimpleSecurityManager based service

If your Service doesn't use credentials or propagate caller credentials: you'll probably need default GCUBESimpleSecurityManager so you have nothing to do. The GCUBESimpleSecurityManager is the default SecurityManager. It allows service in acting in a secure infrastructure, if it doesn't need creds at all or need to act on behalf of a caller. The SecurityManager is able to propagate caller credential from the invocation to the place where they're needed. Here's a simple example where myService should contact another service on behalf of the caller:

// Retrieving caller creds
SecurityManager.useCredentials(SecurityManager.getCallerCredentials)‏
// Invoke target service using its stubs and prepareCall 
GcubeScopeManger.setScope(GcubeScope)‏
GcubeScopeManger.prepareCall(PT, “ServiceName”, “ServiceClass”)‏
// SetSecurity
SecurityManager.setSecurity(PT, GCUBESecurityManger.AuthMode.INTEGRITY, GCUBESecurityManger.Delegation.DelegationMode.FULL)‏

ServiceSecurityManager based service

If your service needs service credentials you need to implement GCUBEServiceSecurityManager, able to manage caller and service credentials. The ServiceSecurityManager allows service in acting in a secure infrastructure if it needs service creds and/or need to act on behalf of a caller This SecurityManager is able to use its own credentials or propagate caller credential from the invocation to the place where they're needed. By correctly setting the jndi file of myService, gCF is able to provide a advanced implementation of the interface you desire

Security vs Scope

gCF has completely decoupled security from scope. In Diligent, we need to extract scope information from the proxy certificate. For this reason, it contained just one privilege among the groups it belongs to in VOMS.In gCube, we have a complete scope management independent from security. I.e.: RI can be shared in different scopes and manage security aspects with one only set of credential.

Overview of the interaction between myService, Delegation and CredentialsRenewal services

The gCube security model exploits the capabilities of a number of actors:

• GCUBEServiceContext as manager of the RI and as GCUBEServiceSecurity Manager;
• GHNContext as orchestrator of the internal events mechanism;
• Delegation Service as requester/dispatcher of credentials for the RIs and CR service as credentials manager for RIs

Most of the details of this interaction are hidden to the gCube developer. To interact with these mechanisms, the developers should:

• Delegate preliminary service owner's credentials to MyProxy CA server.
• create a MyProxyAccount on CR related to account on MyProxy CA server.
• Add contexts to this account

If your service implements GCUBEServiceSecurityManger, at the end of these three steps, the rest will be done for you automatically.

At bootstrap time, Delegation service, co-hosted with your service, will try to create a renewalTask for myService, looking for one set of credentials that matches the scopes and the roles required. Then Delegation service adds that renewalTask to the correct MyProxyAccount, that will be in charge to provide fresh credentials to myService otherwise myService won't be available on the infrastructure.

Use delegated credentials to invoke services

If the service operates in a single DL then you can get credentials from the listener using the getCredentials() method. As shown in the box below. These credentials can be used to authenticate invocations. E.g:

ExtendedGSSCredential creds = this.credentialsListener.getCredentials();
...
ConfigureSecurity.setSecurity(((javax.xml.rpc.Stub) port), creds);
port.yourOperation();
...

If the service operates in multiple DLs then you can get credentials from the listener using the getCredentials(DLName) method. As you see the name of the DL must be passed to the listener in order to retrieve credentials related to a specific DL. As shown in the box below. E.g:

ExtendedGSSCredential dlOneCreds = this.credentialsListener.getCredentials(/diligent/ARTE/DL1);
...
ConfigureSecurity.setSecurity(((javax.xml.rpc.Stub) port), dlOneCreds);
port.yourOperation();
...

Retrieve delegated credentials on service side

To retrieve delegated credentials on service side you can use the code:

import org.globus.gsi.jaas.JaasGssUtil;
import org.globus.gsi.jaas.JaasSubject;
import org.ietf.jgss.GSSCredential;
 
....
GSSCredential cred = JaasGssUtil.getCredential(JaasSubject.getCurrentSubject());

The client must explicitly allows to delegate credentials setting the org.globus.axis.gsi.GSIConstants.GSIConstants.GSI_MODE property in service stubs. To do this you can use the org.diligentproject.dvos.authentication.util.ConfigureSecurity.setSecurity(...) method of the dvos.authentication-api library.