Shared Catalogue - Test Description

GFIVO: Multiple Security Mechanisms Web Services Deployment

Abstract

Grouper WS currently supports both Basic Authentication and WS-Security (via Rampart). However, Grouper WS has to be deployed separately with each deployment supporting a different security mechanism if a developer wishes to support one or more security mechanisms. This report describes the work done in Newcastle with respect to a single Web Service supporting multiple security mechanisms in a single deployment.

Table of Contents

1.Introduction

2.WS-Security Policy

2.1Introduction

2.2Policy Assertion

2.3Conclusions

3.Multi-port Web Services

3.1Introduction

3.2Implementation of Multi-port Web Services for Grouper WS

3.3Conclusions

4.Conclusions

5.References

1. Introduction

The current Grouper WS supports multiple security mechanisms in the form of Basic Authentication and WS-Security (via Rampart). However, a developer who wishes to have both security mechanisms in place will have to deploy Grouper WS separately with a different security mechanism configured for each deployment. The primary reason for this is because a Web Service that is WS-Security enabled expects WS-Security headers in the SOAP request message when called by a client. In the current Grouper WS installation, it is not possible to support both Basic Authentication and WS-Security without separate deployment. This however is not an attractive prospect for us because it means we have to keep deploying extra services if we ever plan to add extra security mechanisms for our Web Services, for example, encryption or digital signatures.

We decided on two approaches after initial research on the subject, policy alternatives and multi-port Web Services. Policy alternatives was our preferred option because it provided an elegant, efficient way of supporting multiple security mechanisms. Multi-port Web Services enables a single service to be deployed on multiple ports with a different security policy attached to each port. However, this appeared a less intricate and inflexible way of supporting multiple security mechanisms because multi-port Web Services is not very well supported by WSDL 2.0.

This report describes our work done on supporting multiple security mechanisms and limitations to each of the options we looked at.

2. WS-Security Policy

2.1 Introduction

The WS-Security Policy [4] specification enables Web Services to have a set of security requirements that must be adhered to, or consumed. Web Service clients that consume a service have to study the security policy for that service and ensure they meet the rules defined in the policy.

WS-Security Policy is built on top of WS-Policy framework and uses policy assertions to define security requirements or constraints for that service. Apache Rampart in turns implements WS-Security Policy. The security policy of this service is always defined in the services.xml of the service.

WS-Security Policy defines 5 main policy assertion types:

Security binding assertions

Protection assertions

Token assertions

Supporting token assertions

Protocol assertions

We will only concentrate on token assertions, and in particular, UsernameToken assertions.

2.2 Policy Assertion

A policy assertion represents a requirement, a constraint or a property. The WS-Security Policy specification provides a set of security policy assertions to enable security for a Web Service in a standardised, interoperable manner. For example, the security assertion in Listing 1 contains a single policy assertion requiring the inclusion of a UsernameToken. Any client that wishes to consume a Web Service that contains this policy has to send a UsernameToken in the form of username/password.

<wsp:Policy>

<wsp:ExactlyOne>

<wsp:All>

<sp:UsernameToken/>

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

Listing 1 A policy document with a single policy assertion

WS-Security Policy also supports policy alternatives. Policy alternatives are collections of policy assertions. For example, the policy document in Listing 2 describes two policy alternatives, the first containing a policy assertion requiring the inclusion of a UsernameToken and the second, an empty policy assertion.

<wsp:Policy>

<wsp:ExactlyOne>

<wsp:All>

<sp:UsernameToken />

</wsp:All>

<wsp:All>

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

Listing 2 A policy document with two policy alternatives

This means that a Web Service with a security policy as defined above will allow both clients with or without WS-Security headers in their SOAP request message. This allows for clients that are either Rampart or Basic Auth enabled to access the Web Service.

Although at first sight the empty policy assertion might appear insecure because it allows any client to call the Web Service, we will however already have Basic Auth deployed for the service. As such, only clients that have the right credentials will be able to access the service.

This is probably the best way to enable a Web Service that supports two different security mechanisms, Basic Auth and WS-Security (enabled by Rampart). It is an elegant approach to supporting multiple security mechanisms and the client side does not have to do anything to support multiple security mechanisms.

However, the major limitation to the policy alternatives approach is that it is not currently supported by Rampart or any other Web Service implementation stack because of performance issues. This caused some confusion for us because there are various articles on the Rampart site on WS-Security Policy and policy alternatives, so it is natural to assume they would support policy alternatives.

2.3 Conclusions

Policy alternatives would have been the best approach to supporting multiple security mechanisms for a single service. The only change that needs to be made to the service deployment is including policy alternatives in the service.xml file. However, the lack of support for policy alternatives by any of the main implementation stacks including Apache Rampart means that this is not an option we can pursue.

3. Multi-port Web Services

3.1 Introduction

The second option for implementing multiple security mechanisms is by deploying multi-port Web Services. In this instance, the same service is deployed to two or more ports and each port has a different security policy. For example, Grouper WS can be deployed to ports 8080 and 8081 with a different policy attached to each port.

Deploying multi-port Web Services is not as easy as it was with WSDL 1.0. As pointed out by Rich Salz in his review of WSDL 2.0 [3]:

“In WSDL 1.0, a service could implement multiple ports. This fits with the conventional model for implementing IETF/Internet servers: each TCP port defines its own language (SMTP, NNTP, etc.), and a single executable can implement multiple protocols, by using the port number to de-multiplex (or dispatch) to the appropriate handlers.”

Deploying multi-port Web Services with WSDL 2.0 appears more intricate and is not as obvious. There is not much literature on the subject and it appears most developers are content to deploy the same service twice and with each deployment containing a different security policy. This is in contrast to our need of deploying the same service only once and the service incorporating multiple security mechanisms. The following section describes our work on deploying multi-port Web Services.

3.2 Implementation of Multi-port Web Services for Grouper WS

This section will briefly explain the Axis2 Transport Framework. Much of the information about the Axis 2 Transport Framework was derived from [1] and [2], which are possibly the only articles we have come across on the topic.

In the case of an incoming message, a TransportReceiver processes a message and sends it to the MessageReceiver. The TransportReceiver essentially listens to incoming messages at specified ports. Axis2 by default listens to incoming messages at port 8080 for HTTP while the default port is 9000 for HTTPS. Extra TransportReceivers can be registered in axis2.xml as shown below:

<transportReceiver name="httpbasic"

class="org.apache.axis2.transport.http.SimpleHTTPServer">

</transportReceiver>

<transportReceiver name="httpwssec"

class="org.apache.axis2.transport.http.SimpleHTTPServer">

</transportReceiver>

Listing 3 Registering extra TransportRecivers with axis2.xml

In the case of an outgoing message, the TransportSender processes and sends the request message. Extra TransportSenders can be registered in axis2.xml as shown below:

<transportSender name="httpbasic"

class="org.apache.axis2.transport.http.CommonsHTTPTransportSender">

<parameter name="Transfer-Encoding">chunked</parameter>

</transportSender>

<transportSender name="httpwssec"

class="org.apache.axis2.transport.http.CommonsHTTPTransportSender">

<parameter name="Transfer-Encoding">chunked</parameter>

</transportSender>

Listing 4 Registering extra TransportRecivers with axis2.xml

The new transport tags now need to be added to the services.xml file as shown below:

<transports>
<transport>httpbasic</transport>
</transports>
<transports>
<transport>httpwssec</transport>
</transports>

Listing 5 Adding new transport tags to services.xml

Unfortunately, we could not go much further with respect to multi-port Web Services. Although in theory adding extra TransportReceivers and TransportSenders in this fashion should work, we however came across exceptions. We posted our problem on numerous Web Service forums but without any luck. It appears that not much work is done on multi-port Web Services and as such, there is not enough information regarding TransportReceivers and TransportSenders to make it work.

3.3 Conclusions

Multi-port Web Services is the second and probably less favourable option to implementing multiple security mechanisms for a single service. However, it has proved troublesome to implement and we cannot proceed further without help on the problems we are currently facing.

4. Conclusions

We have detailed the two options we believe could be used to replace the current security mechanism in place for Grouper WS. We, in Newcastle University, would like a security scheme whereby the Grouper WS is deployed only once but is able to incorporate two security mechanisms, Basic Authentication and WS-Security (via Rampart).

We firstly looked at policy alternatives, whereby a Web Service has a security policy that defines one or more security mechanisms. This was without doubt the most attractive option because any client that is either WS-Security enabled (via Rampart) or Basic Auth enabled can access a service without much configuration on either the client or service side. However, we found out that policy alternatives is not implemented by Rampart or any other Web Services implementation stack. As such, policy alternatives is not an option we can pursue for the foreseeable future.

The second option we looked at was multi-port Web Services. In this scenario, the same service is deployed to one or more ports but with a different security policy at each port. Although WSDL 1.0 ably supported multi-port Web Services, this is not however the case with WSDL 2.0. Implementing multi-port Web Services with WSDL 2.0 proved troublesome because there is not much literature on the subject. It also appears that there is not much development regarding multi-port Web Services. The immaturity of multi-port Web Services makes it a difficult technology to implement or recommend.

In conclusion, although the current security implementation of Grouper WS of deploying a service twice for different security mechanisms is rather inelegant, it is however a very practical, workable approach. The alternatives to this approach are not feasible at the moment and as such, we are very content to continue implementing the security infrastructure for Grouper WS by deploying the web service application twice and placing a different mechanism on each deployment.

5. References

Axis 2 Transport Framework -
HTTP Transport –
WSDL 2.0. Just Say No -
WS-Security Policy specification -