How To Configure Service Security

From Gcube Wiki
Revision as of 14:03, 20 May 2009 by Andrea.turli (Talk | contribs)

Jump to: navigation, search

Alert icon2.gif 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)

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());

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

Add Authorization

Create the VO-Handler configuration file

In order to enforce authorization you have to create a mapping between service operations and logical operations. This mapping is keep in the YourServiceHandler.properties in the "etc" directory of your service. For an example see Media:YourServiceHandler.properties

Modify WSSD to add VO-Handler

The WSSD must be modified to enforce authorization using the VOAuthorizationHandler You have to replace the element

<authz value="none"/>

with following content:

<authz value=
"VOAuthorizationPDP:org.diligentproject.dvos.authorization.handler.VOAuthorizationPDP"/>

Modify WSDD to set handler properties

You have also to tells the VOAuthorization handler where to find the configuration file and the VOMS certificates to verify authorizations. To do this add following lines to your WSDD file:

<parameter name="VOAuthorizationPDP-VOAuthorizationHandlerFile"
  value="@config.dir@/YourServiceHandler.properties"/>

<parameter name="VOAuthorizationPDP-VOMSCertificateDirectory" value="/etc/grid-security/vomsdir/*"/>

Now the service part of the authorization is set up. Redeploy your service and restart the container.

Access a service using authorization

In this step you'll try to access the deployed service with a client using authentication and authorization First of all try to contact your service using an authenticated client and a plain proxy, you should get following Axis fault:

org.globus.wsrf.impl.security.authorization.exceptions.AuthorizationException: 
... is not authorized to use operation: ... on this service

To access the service with authroization you need to use a certificate containing a VOMS role entitled to perform operation invoked.

Extend DILIGENT authorization

Check for Authorization using the VOQuery API library

Define new authorization handlers