Difference between revisions of "How To Configure Service Security"
(→Set credentials on service stubs) |
(→Use delegated credentials to invoke services) |
||
Line 127: | Line 127: | ||
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: | 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(port, creds); | ConfigureSecurity.setSecurity(port, creds); | ||
Line 135: | Line 135: | ||
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: | 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(port, dlOneCreds); | ConfigureSecurity.setSecurity(port, dlOneCreds); |
Revision as of 15:46, 11 September 2007
This page contains useful information for DILIGENT developers about configuration of services to comply with the DILIGENT Security Model.
Contents
Configure service authentication
This configuration protect 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 DHN Security page describes steps needed to set-up such a container.
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://www.diligentproject.org/namespaces/..." operation.
This means that the GSI Secure Conversation mechanism is required to invoke the service. To enable it perform following steps.
Set credentials on service stubs
Use following lines to load your proxy credentials and use them to contact the service
import org.diligentproject.dvos.authentication.util.ConfigureSecurity; import org.ietf.jgss.GSSCredential; ... GSSCredential cred = ConfigureSecurity.loadProxyCredentials("yourProxyFile"); ... YourServicePortType port = ...<getPortType> ConfigureSecurity.setSecurity(((javax.xml.rpc.Stub) port), cred);
Don't forget to add the client-config.wsdd
file in the directory where you run the client. You can, instead, add the $GLOBUS_LOCATION
as the first entry of your classpath.
Then you should be able to contact your service using your credentials
Get the DL of the caller
Following code allows to extract from credentials the name of the community and the name of the DL where credentials are operating.
org.gridforum.jgss.ExtendedGSSCredential credentials = ... org.diligentproject.dvos.authentication.util.DILIGENTVomsAttributesReader d; d = new DILIGENTVomsAttributesReader(credentials); String communityName = d.getCommunity(); String DLName = d.getDL(); String absoluteDLName = d.getAbsoluteDLName());
The getCommunity() method return the name of the community as String (E.g.: impect).
The getDL() method return the name of the DL as String (E.g.: OceanDL).
The getAbsoluteDLName() method return the absolute name of the DL as String (E.g.: /diligent/impect/OceanDL).
Provide your service with credentials
This step enable your service to authenticating itself in outcoming requests it performs to other services. Two ways can be followed to provide credentials to your service:
- Use the DILIGENT Delegation service (as described in following section)
- Use the delegation mechanism embedded in the GSISecureConversation protocol. For detials of this option refers to section How To Configure Service Security#Use_the_GSISecureConversation_delegation
Register to the local Delegation service
In your service, usually during initialization, you should create a new CredentialsListener
and register it to the local DelegationLocalInterface
. The listener will be notified when fresh credentials will be received for your service.
Two classes of listeners are available (and others can be implemented by developers if needed). The one to use depends on the scenario adopted by your service (refers to the DILIGENT Security Model page for more information about identity scenario). If your service operates in a single DL it needs only a single copy of credentials. The service does not have to choose the DL where it is operating. If the service operaties in multiple DLs, instead, it needs to choose credentials to use to perform invocations.
If the service operates in a single DL the listener to use is the SingleCredentialsListener one. This listener is able to store only a single copy of credentials, regardless the DL these credentials refers to. The registration in this case looks like the one in the box below.
credentialsListener = new SimpleCredentialsListener(); DelegationLocalInterface.registerCredentialsListener(this.credentialsListener);
Previous lines of codes are usually added to the constructor of the class implementing service operations. E.g:
public class VOAdministrationService { ... private SimpleCredentialsListener credentialsListener; ... /* Constructor */ public VOAdministrationService() throws ResourceContextException, ResourceException { this.credentialsListener = new SimpleCredentialsListener(); DelegationLocalInterface.registerCredentialsListener(this.credentialsListener); }
If the service operates in multiple DLs the listener to use is the MultipleCredentialsListener one. This listener is able to store credentials based on the DL they refers to. The registration in this case looks like the one in the box below.
credentialsListener = new MultipleCredentialsListener(); DelegationLocalInterface.registerCredentialsListener(this.credentialsListener);
Previous lines of codes are usually added to the constructor of the class implementing service operations. E.g:
public class VOAdministrationService { ... private MultipleCredentialsListener credentialsListener; ... /* Constructor */ public VOAdministrationService() throws ResourceContextException, ResourceException { this.credentialsListener = new MultipleCredentialsListener(); DelegationLocalInterface.registerCredentialsListener(this.credentialsListener); }
At this point compile and deploy again your service and restart the container. To test the configuration of your service you have to put credentials on MyProxy and set-up a credentials renewal task as described in How To Configure Identities For DILIGENT Services
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(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(port, dlOneCreds); port.yourOperation(); ...
Use the GSISecureConversation delegation
This section gives some hints about how to use the delegation mechanism built into the GSISecureConversation mechanism.
Configure the service WSSD to ask client credentials delegation
To use this delegation method you have to set caller-identity
as run-as mode in the Web Service Security Descriptor (WSSD) of your service. This is described in details here.
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.
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.