Stopgap Sign-on for myGrid

Introduction

This topic describes the stopgap sign-on capabilities as discussed in the Access Grid meeting and telecon on 11 Jan 2005 and the CI meeting in Southampton on 12 Jan 2005.

We agreed that OMII-based implementation is not feasible within the duration of the current project:

• the necessary client & server side changes are large
• the likelihood of library mismatches between OMII & myGrid code
• OMII is currently limited to SuSE & PostgreSQL

We therefore fall back to Tomcat (servlet) security.

Similarly, we do not think it practicable to use Person LSIDs as usernames, which would require implementing an "MIRRealm" for deployment in Tomcat and a corresponding MIR port type.

Thus we are back to using username/password pairs held in a Tomcat configuration file. These usernames would not be attributes of Person objects in the MIR.

See SecurityArchitecture for other aspects of security and further background information.

Overview

The overall approach is that:

• clients (e.g. Taverna, portlets) will solicit username/password pairs from users and pass them on each service invocation

• intermediaries (Mediator, LSID data/metadata) will extract username/password pairs from incoming requests, and will pass them pass on each service invocation made by the operation implementation. Intermediaries will not require further implementation

• end services (that do not call other myGrid service components) will be configured to accept username/password pairs from clients

Taverna invokes the enactor either in-process or as a web service:

• in-process: Taverna will a solicit username/password pair from the client and pass them to Freefluo which in turn passes them to any event-observer plug-ins

• as a web service: Taverna will solicit a username/password pair from the client and use them to authenticate to the Freefluo web service; Freefluo will be configured with a single username/password pair that it will pass to any event-observer plug-ins pass them to Freefluo

In both both cases, the event-observer plug-ins will use username/password pair received from Freefluo to authenticate to any myGrid service.

Changes in detail

1. Handling username/password 'on the wire'

1.1 Client side:

Any invocation of a myGrid service or intermediary will need to encode the username/password pair in the HTTP header of any SOAP invocation. Axis supports this with the methods setUsername() and setPassword() on class org.apache.axis.client.Call and org.apache.axis.client.Stub. See http://www.jdocs.com/axis/1.1/api/index.html.

A typical Axis dynamic invocation might be as follows:

  try {
    String   endpoint  = ...;
    String   username  = ...;
    String   password  = ...;
    String   operation = ...;
    Object[] params    = ...;
    
    Service  service   = new Service();
    Call     call      = (Call) service.createCall();
    
    call.setTargetEndpointAddress (new java.net.URL(endpoint));
    call.setOperationName (new QName(operation));
       
    call.setUsername (username);
    call.setPassword (password);

    Object result = call.invoke (params);
  } catch (Exception e) {
    System.err.println(e.toString());
  }

Unfortunately, stub-based invocations require a cast. For some port type MyService, the generated service locator class MyServiceLocator contains a method:

  public MyServicePortType getMyService()
    throws javax.xml.rpc.ServiceException
  {
    ...
  }

where MyServicePortType is a Java interface whose only operations are those defined in the service's WSDL. This needs to be cast to either org.axis.client.Stub (or its generated subtype MyServiceBindingImpl), e.g.:

  try {
    String   endpoint  = ...;
    String   username  = ...;
    String   password  = ...;
    
    MyServiceBindingImpl service = (MyServiceBindingImpl)
      new MyServiceLocator().getMyService(endpoint);
       
    service.setUsername (username);
    service.setPassword (password);

    ResultType result = service.someOperation (...);
  } catch (Exception e) {
    System.err.println(e.toString());
  }

Axis uses the WS-Security format on the wire, and server-side Axis will authenticate against the correct Tomcat Realm.

1.2 Server side

Actual authentication will be performed by Axis itself, from information stored in the servlet's web.xml descriptor. This must be configured-in by the user, which unfortunately means that the user must unpack the WAR or edit the file in place in Tomcat's files after deployment.

Tomact/Axis based services can retrieve username and password from incoming operation requests as follows:

  org.apache.axis.MessageContext messageContext =
    org.apache.axis.MessageContext.getCurrentContext();
  String username = messageContext.getUsername();
  String password = messageContext.getPassword();

In LSID services, the same information can be obtained from the LSID request context, which is the first parameter to the services' operation implementations (named req in the interface specifications). E.g.:

  import com.ibm.lsid.LSIDCredentials;
  import om.ibm.lsid.server.LSIDRequestContext;
  import com.ibm.lsid.server.impl.SimpleResolutionService;

  public class MyDataService extends SimpleResolutionService
  {

    public java.io.InputStream getData(LSIDRequestContext req)
    {
      LSIDCredentials credentials = req.getCredentials();
      String username =
        credentials.getProperty(LSIDCredentials.BASICUSERNAME);
      String password =
        credentials.getProperty(LSIDCredentials.BASICPASSWORD);
      ...
     }
     ...
   }

This code can be used in intermediaries to pass the credentials on to further services, or for reporting.

2. Getting the username/password from the client

This requires a change to the MIRBrowser. Currently, opening the MIRBrowser presents the user with a list of Person names & a password field (which it ignores). This will need changing to a two-step dialogue:

• The initial step will prompt for the (Tomcat) username/password pair, which the MIRBrowser will store in the user context
• The second step will present the list of Person names as before (and store the selected Person's LSID in the user context)

3. Modifying Taverna/Freefluo context handling

The Taverna & Freefluo context needs changing to hold the a username/password pair as well as the Person LSID in the user context.

As described in the overview above, Taverna will supply the user's username/password to an in-process Freefluo. If Taverna is configured to use a Freefluo web service, it will use the user's username/password to authenticate to Freefluo, but the existing Freefluo port type need not be changed.

The Freefluo web service 'wrapper' will construct a context containing its configured username/password (and current information) and pass it to the enactor core.

4. Invoking myGrid services:

Each invocation of a myGrid service will need to encode and marshal a username/password pair via the Axis APIs described in (1) above.

The workflow event observers (MIR, KAVE, Mediator) will use the username/password from the modified context implemented in (3) above.

Intermediaries (lsid-metadata, lsid-data(?), Freefluo WS, Mediator) will use the username/password held in configuration data.

Who: Chris (lsid-metadata, Arijit (lsid-data), Justin (Freefluo WS), Nedim (Mediator) Cost: 2 days each?

The MIR init program will prompt the user at the command line

2. Using HTTPS (HTTP over SSL)

Because basic authentication places unencrypted credentials in each SOAP request, we will encourage use of HTTPS to provide greater confidentiality. This can be achieved by configuration, without source code changes, except for one detail.

SSL can work with either both client and server side certificates, or server side certificate only. In the latter case, the client may need to have access to the server side certificate: this is in fact the default for Axis-based services. To reduce configuration overheads, we will override the default so that the client need not have access to the server's certificate.

We therefore need to extend the notes at http://www-106.ibm.com/developerworks/webservices/library/ws-sec1.html with one further detail: we must arrange that the following System property (or better, Axis property) is set as shown in clients and intermediaries:

  axis.socketSecureFactory = org.apache.axis.components.net.SunFakeTrustSocketFactory

Taverna already includes a more sophisticated approach that also achieves this end. Coding suggestions for other myGrid components to be upplied.

On the server side, users must create a keystore and a self-certificate and modify Tomcat configuration.

On the client side, applications must use service URLs containing the https protocol and identifying the relevant Tomcat installation's SSL port (default 8443). With the above secure socket factory setting, clients do not need to access a keystore or certificates, so the same client-side code given in (1) will work whether or not SSL is used.

The configuration tasks must be described in the myGrid Installation Guide.

6. Portal

Can we integrate this approach into the GridSphere^? sign-on process? Does GridSphere^? use the usual Tomcat MemoryRealm by default? myGrid service invocation would be as described in (4) for intermediaries.

-- NickSharman - 19 Jan 2005 -- NickSharman - 16 Feb 2005 (from information supplied by JustinFerris)