Difference between revisions of "How To Configure Service Security"

Revision as of 16:27, 20 May 2009

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