gsi and web services neil p chue hong [email protected] workshop on web services 1

GSI and Web Services

Neil P Chue [email protected]

Workshop on Web Services 1

2 GSI and Web Services - WoWS1 20/3/2002 - Neil Chue Hong - [email protected]

Summary

Background

Tools and Applications

Implementing a GSIHTTP enabled server

A simple GSI Web Service and Client

Over to you…


Motivation

Why should we develop GSI-enabled web services?– We can use our existing GSI proxy certificates to provide a

security mechanism and the same single sign-on mechanism for our web services.

– We can use this as a starting point for developing

OGSA Grid Services– We can (in theory) develop clients and services in different

languages and they should just work…

Caveat: I am not a security expert!


Security and Web Services

The base SOAP specification does not define any authentication / authorisation mechanisms

Questions to ask:– How can I prove who I am? (authentication)– How can I tell if you’re allowed to access the services that I

offer? (authorisation)– How do we negotiate my ability to access the services you

offer? (administration)– How can we protect the integrity of our transactions? (secure

communications)– How do we know whether or not we can trust each other?

(trust relationships)


GSI

Grid Security Infrastructure (GSI)– Based on Generic Security Services API (GSS-API)– Uses an extension to X509 certificates

Provides a mechanism to:– Authenticate a subject– Authorise a resource– Implement a single sign-on mechnism

Current implementation does this using:– Proxy certificates and Certification Authorities (this really is

me!)– Gridmap file (let me use the resources available to a local

user/account!)


GSI and Web Services

We can use GSI to provide security for web services we deploy

Use the header to send delegated credentials from the client to the service

The service can use the credentials to authenticate the user and authorise access to the service.

ANL have released some sample code to do this using Tomcat and Axis.


Tomcat

Tomcat is a stable, mature reference implementation of a servlet container for Java Servlets and Java Server Pages.

It allows you to run web applications. Source code is available and open source. It can be used as a platform to deploy the Axis

toolkit.

See: http://jakarta.apache.org/tomcat/


Axis

Axis is an implementation of the SOAP 1.1 (and SOAP with Attachments) protocol in Java

Written for performance and extensibility It has a flexible architecture:

– Easier to use other transports (e.g. https, smtp, ftp)• core engine is transport independent

– Easier to add other code in message handling such as• encryption• logging• authentication

– Also easy to deploy and administer Web Services using Axis

See: http://xml.apache.org/axis/


Axis Architecture

Axis has two handler “chains”– Global– Transport specific– Fairly stable APIs

– We will create a new

request handler for GSI HTTP

Axisengine

WebService

TransportRequestor

Request Handlers

Response Handlers

Web Service specific chainTaken from Building Web Services with Java, by Steve Graham et al.


Altering Tomcat to support GSI (1)

A few “hacks” have been made to Tomcat:– CertificatesValve.java

• Patch made which alters expose() method

• Instead of exposing SSL session it exposes the GSI credentials

– GSISocket.java• Extends SSLSocket.java to provide Globus proxy / delegated

credentials support

– GSIServerSocketFactory.java• Implements ServerSocketFactory to allow creation of GSISockets

• This file contains hardcoded locations of the hostcert.pem, hostkey.pem, certificates and grid-mapfile files.

– Currently dependent on IAIK Java cryptography libraries


Altering Tomcat to support GSI (2)

Some changes are needed to the Tomcat configuration (conf/server.xml)

Add a new Connector to the <service> section– Define a GSI HTTP/1.1 Connector on port 8443– Define which Factory object should be used

(GSIServerSocketFactory)• This also contains hardcoded locations of proxy, usercert,

userkey and certificates directory (which are different…)

Add a new Valve to the <engine> section– This tells Tomcat to use the modified CertificatesValve object

Tomcat should now accept httpg: requests on port 8443


Adding a GSI Handler using Axis

Handling GSI in Axis– GSIHTTPTransport.java

• Sets up a new transport, httpg, within Axis

– GSIHTTPSender.java• New handler for GSI HTTP (uses MessageContext.getProperty())

– GSIAdminClient.java• Registers the new handler with the transport in Axis

– Util.java• getCredentials(msgContext) return the proxy credentials

associated with the message context

• registerTransport() registers the GSIHTTPTransport class for the httpg protocol

• Also used by client programs (see later)


Installing the modified code

ANL provide precompiled jars to replace catalina.jar and axis.jar

Or you can “roll your own” and compile from source

Replace jars, restart Tomcat and you’re ready to write GSI web services

Also required are Java CoG kit (cog.jar), and IAIK cryptographic libraries (iaik_ssl.jar, iaik_jce_full.jar, iaik_javax_crypto.jar, cryptix.jar)


Writing a GSI Web Service (1)

Let’s write a service, MyService, with a method, serviceMethod, which takes one argument.

The Axis RPC dispatcher will look for the same method with an extra parameter (the message context) when it receives a GSI enabled client invocation

So we add this extra parameter to the method Util.getCredentials() allows us to access the

GSI proxy from the message context


Writing a GSI Web Service (2)

Here’s the code:

This just prints the credentials and string sent

import org.apache.axis.MessageContext;

import org.globus.axis.util.Util;

public classMyService {

// Add a MessageContext argument to the normal method

public String serviceMethod(MessageContext ctx, String arg) {

System.out.println(“MyService: you sent “ + arg);

System.out.println(“GOT PROXY: “ + Util.getCredentials(ctx));

return arg;

}

}


Writing a GSI Web Client (1)

Similar to writing a normal web services client:– Deploy a httpg transport chain– Use the Java CoG kit to load a Globus proxy– Use setProperty() to set GSI specific SOAP headers

• globus credentials (the proxy certificate)

• authorisation type

• GSI mode (SSL, no delegation, full delegation, limited delegation)

– Then do rest of normal SOAP routine• setTargetEndpointAddress()

• setOperationName()

• addParameter()

• setReturnType()

• Invoke()


Writing a GSI Web Client (2)

Here’s (most of) the code:SimpleProvider provider = new SimpleProvider();

SimpleTargetedChain chain = new SimpleTargetedChain(new GSIHTTPSender());

provider.deployTransport(“httpg”, chain);

GlobusProxy proxy = GlobusProxy.getDefaultUserProxy();

Service service = new Service(provider);

Call call = (Call) service.createCall();

call.setProperty(GSIHTTPTransport.GSI_CREDENTIALS, proxy);

call.setProperty(GSIHTTPTransport.GSI_AUTHORIZATION, new SelfAuthorisation(proxy));

call.setProperty(GSIHTTPTransport.GSI_MODE, GSIHTTPTransport.GSI_MODE_LIMITED_DELEG);

call.setTargetEndpointAddress(new java.net.URL(“httpg://localhost:8443/axis/servlet/AxisServlet”));

call.setOperationName(new QName.(“MyService”, “serviceMethod”));

call.addParameter(“arg1”, XMLType.XSD_STRING, ParameterMode.PARAM_MODE_IN);

call.setReturnType(XMLType.XSD_STRING);

String ret = (String) call.invoke(new Object[] { “Hello World” });

System.out.println(“MyService returned: “ + ret);


Running a GSI Web Client/Service

It should just work…


Experiences of GSI and Web Services

… but it didn’t

Two main difficulties:– Authentication or authorisation is failing– Can’t probe SOAP message (it’s encrypted)

So can’t tell why it’s failing Documentation of GSI Web Services and Axis

is sparse However…

– I understand the code a lot better after having to write this talk!


What happens next?

Document code and provide proper instructions

Recompile additions against latest releases of Tomcat and Axis

Distribute source, binaries and documentation to UK eScience community (by end of March?)

Ideally, provide another example client e.g. using Python


The benefit of open standards

There are a number of other attempts to produce secure XML and SOAP messaging standards– XML Digital Signatures– SAML – security-based assertions– XKMS – providing and managing PKI-based web services– XACML – access control framework for XML

See: http://www.w3c.org, http://www.oasis-open.org And an odd one out:

– Microsoft Passport

Which one will be adopted in the end?


Summary

Web services are good Secure web services are better

We can write secure web services using GSI We can communicate securely with web

services using GSIHTTP It should just work

I will be providing code examples


The End

Over to you…

gsi and web services neil p chue hong [email protected] workshop on web services 1

Documents

web services wows1

gsienabled web services

web services neil p

web applications

simple gsi web service

neil chue hong

ogsa grid services

axis axis