Introduction

GRIA's approach is to only adopt standards that can be safely used in B2B scenarios where infrastructure that can support strict but flexible export policies is critical. Prior to implementation, each specification is analysed in detail to understand the benefits and issues associated with adoption. GRIA does not compromise security constraints against interoperability requirements.

It should be noted that many of the key specifications are evolving and compliance tests do not exist today, apart from the WS-I Basic Profile. Different interpretations of the specifications and lack of compliance tests makes true interoperability difficult to achieve in practice, and requires interoperabilty testing between different systems. GRIA cannot guarantee interoperability with other systems based on the standards described below. In some cases, GRIA only implements part of the specifications or adopts a similar interaction pattern to achieve the desired functionality for the end users.The following sections describe how GRIA uses key Grid and Web Service interoperability specifications to achieve important functionality.

WS-I Basic Profile

The WS-I Basic Profile 1.0 is a set of specifications that attempts to improve Web services interoperability by defining how developers should implement core specifications WSDL, SOAP and UDDI.

GRIA builds on Apache AXIS open source Web Service middleware which is compliant to WS-Basic Profile 1.0. All GRIA services use the "document/literal" encoding.

WS-I Basic Security Profile

The WS-I Basic Security Profile provides guidance on the use of WS-Security and the REL, Kerberos, SAML, UserName and X.509 security token formats. WS-Security is a set of SOAP extensions to provide message-level integrity, confidentiality and authentication. WS-Security enables collaboration between other Web Service security standards and protocols. It does not dictate one specific security technology, and allows organizations to use heterogeneous security models and encryption technologies for multiple security tokens, trust domains, signature formats, and encryption technologies.

GRIA uses both transport and message-level security, based on open source middleware.

At the transport level, GRIA uses SSL (provided by the Apache HTTP Server or by Tomcat) to support encrypted HTTPS connections between clients and services, and to allow the client to authenticate the service based on its X.509 certificate before sending it any data. Once the connection is set up, HTTPS encryption ensures the confidentiality of any data subsequently transferred between the two.

At the message level, WS-Security is used to provide separate authentication and integrity of message content, based on the Apache WSS4J implementation. This allows the service to authenticate the client's request messages, based on the client's X.509 certificate, and ensures that neither side can repudiate messages after they have been sent.

Some GRIA services also issue SAML tokens to encode assertions about the role of individual users with respect to the issuing service. These tokens allow other services to verify that their subject has a particular role. These tokens allow GRIA to federate security policies between domains using WS-Federation patterns (see Scaleable Relationship Management using WS-Federation, below). WS-Federation is not yet established in the WS-I Basic Security Profile, so GRIA does not yet use the WS-I SAML token profiles for this.

Secure WS-Addressing

WS-Addressing was originally designed as a way to convey connection state or context in SOAP messages, emulating the contextualisation mechanism provided by HTTP headers in conjunction with stored cookies. This makes it possible to contextualise message exchanges in a similar way, independently of the transport used.

To support this, WS-Addressing provides a schema for an "endpoint reference" (EPR), which can be used to specify where the response should be sent, and the context headers that should be attached (specified within the EPR through "reference parameters"). The EPR can thus convey a fully qualified and contextualised message destination, and is starting to be used not only to specify the headers needed in a reply but also to specify onward routing destinations and headers. In this case, the reference parameters are supposed to be treated as opaque by the initial recipient, who is obliged to simply transcribe any reference parameters into the SOAP header of the forwarded message.

The problem with WS-Addressing is that it allows a sender to force a recipient to transmit a (signed) message to a third party, including SOAP headers of the sender's choosing. This can be abused in the same way that email relaying is used by spammers - to make a message appear to come from someone else. When used with message-level signatures, WS-Addressing is actually worse than spam relaying, because the message is signed by the innocent intermediary and so is more likely to be trusted by the eventual final recipient. The problem is most serious when the EPR specifying the response is carried in a WS-Addressing ReplyTo or FaultTo element, which tells the recipient to send a response as specified. However, it also arises if EPRs are used simply to represent addresses in a standard way, and WS-Addressing rules used to decode the address for subsequent (not necessarily response) messages.

WS-Addressing provides an escape clause that allows anyone constructing a message from an EPR to leave out any message headers they don't think are safe, even if the WS-Addressing specification says they should be included. This removes the security risk, but it means nobody can be sure what parts of a WS-Addressing EPR will be processed.

GRIA overcomes these problems by avoiding the use of WS-Addressing ReplyTo or FaultTo elements, and by defining "white lists" of reference parameters (and also HTTP arguments) that it will honour if passed to it via an EPR.

A Basic WSRF Profile

WSRF is a collection of related specifications coordinated by OASIS, intended to define a generic and open framework for modelling and accessing stateful resources using Web Services. WSRF has been adopted by some outside the Grid community, though it is only one of several competing proposals for treating state and stateful resources encapsulated in Web Services.

WSRF uses WS-Addressing to carry context identifiers for specific server-side resources known as WS-Resources, and specifies an XML document encoding of properties of these resources, plus get, set and query operations to access and update the properties of a WS-Resource. These are used to publish WS-ResourceLifetime data, which also supports scheduled or immediate WS-Resource destruction. Finally, WS-ServiceGroup provides a way to create collections of service endpoints characterised by their resource properties, and to search these collections using resource property queries.

Resource properties present a security problem: some properties should have restricted access, but the access operations select which properties are returned based on input arguments (query terms), so the security policy must be aware of the semantics of resource properties and query languages. Unless this problem is addressed (e.g. by an argument-aware and query language-aware security infrastructure), it is hard to use WSRF except in a very limited way. WS-ResourceLifetime can be adopted but without exposing the lifetime properties (unless they are the only properties of the WS-Resource), but WS-ServiceGroup is more problematic, as it combines resource properties from the services in a collection in a single WS-Resource. Defining security policies for resource properties of this collection, such that the policies of the member services are respected, requires an even more sophisticated dynamic security implementation.

GRIA conforms to the WS-Addressing specification in the following ways.

• Adopting a secure WS-Addressing profile.

• Adopting the WS-Resource specification, but using a single context identifier element (http://www.it-innovation.soton.ac.uk/2005/grid/ConversationID) for all services, and retaining a minimal white list containing only this chosen identifier element when processing WS-Addressing EPR.

• Implementing the GetResourceProperty mandatory operation only from WS-ResourceProperties, but declaring no resource properties in the first instance.

• Defining a BaseFault to be returned whenever a user attempts to access a contextualised service using a ConversationID for which they are not authorised or which does not exist.

• Adopting BaseFaults in all other cases.

Usage Monitoring with WS-Notification

The WS-Notification family of specifications were originally developed to fulfil the need identified by many members of the Grid community for notification messages to be passed between components of a Grid infrastructure. This requirement was originally motivated by the fact that Grid applications tend to be computationally complex, and tend to require long execution times even on high-performance computing platforms. The simplest WSN specification is Web Services Base Notification (WS-BaseNotification) which defines a "publish-subscribe" pattern for transmitting notification messages between a NotificationProvider and a registered NotificationConsumer. WS-BaseNotification defines a push-style notification for subscribers who want notifications on specific topics, and a pull-style message delivery mechanism designed for use by consumers to whom notifications cannot be delivered, e.g. because they are behind a firewall.

GRIA uses pull-style notification to deliver usage reports generated by application services to the SLA management service. Application services generate metric usage reports that are stored on a notification message queue. The SLA management service periodically retrieves these usage reports using the WS-N pullpoint associated with each application service.

Usage Monitoring with WS-Notification

GRIA does not implement the full WS-BaseNotification functionality because it does not need it. Each application service is managed by a single Service Provider Management service, and the relationship between them is constrained by the fact that they have to trust each other. This means that both are usually controlled by the same service provider, who configures the services to know about each other, so the management service does not need to subscribe to receive notifications from application services. Moreover, each application service has a single PullPoint interface through which all its usage reports are sent, so there is no need for the management service to create and manage its own PullPoints.

Application services that want to use GRIA Service Provider Management have to do three things:

• ask the management service layer before creating a new WS-Resource;

• generate usage reports from each resource that is running and make them available through a PullPoint, as shown in the above diagram; and

• support the WS-ResourceLifetime destroy operation, and allow the Management service to use it to kill resources that overconsume the application service.

In future versions of GRIA, it is possible that a more general purpose notification system will be introduced, and the simple trust assumptions in GRIA 5 generalized. By using parts of the WS-BaseNotification and WS-ResourceLifetime specifications at this stage, we aim to minimise changes for application service developers as the management models evolve.

Scaleable Relationship Management using WS-Federation

GRIA uses the WS-Federation pattern to allow clients and service providers to quickly establish trusted business relationships, and to allow access control to be managed in a scalable way locally to the client organisation.

WS-Federation describes how to use WS-Trust, WS-Security and WS-Policy together to provide federation between security domains. The specification defines a number of variations on the exchange of security tokens (a set of claims about a client) between domains, using security token services (STS) that issue or validate security tokens. For example, a client can send a message to a service provider signed by the client's token service, leaving the Web Service to call its own token service for validation, converting the token into one it can understand if necessary. Alternatively, the user can call a service provider or third party token service to get a token the Web Service can understand. WS-Federation can also be used to implement a "delegation" model, in which the user provides a security token to their delegate using the mechanism described in WS-Trust. The delegate then includes this token in any messages they send to the service, allowing the service to understand for whom the delegate is working.

WS-Federation does not define any standard way to establish this trust relationship dynamically. According to the specification "The following topics are outside the scope of this document: Definition of message security or trust establishment/verification protocols...". Therefore, trust relationships must already exist between the WS-Trust token services in a WS-Federation exchange. Although these two specifications describe the message exchanges needed, they do not solve the problem of dynamic trust and security federation.

GRIA uses the WS-Federation pattern but explicitly defines through an e-Commerce business process how trust is dynamically established between a client and service provider. GRIA provides a client management service and a service provider trade account service to manage the federated relationship. These services issue users with SAML security tokens that assert their level of trust within a given business relationship, and these are transmitted to service providers with service requests, and verified by the service provider according to the WS-Federation pattern.

This federation mechanism can be used to set up and police relationships between project accounts in a consumer organisation (against which tokens are issued to authorised users) and any service-managed resource from the service provider that can validate these tokens. GRIA uses this mechanism to associate project accounts with service provider trade accounts, signifying that authorised users are allowed to charge services to the trade account. It can also associate project accounts with SLAs negotiated with service providers, whereupon authorised users can present tokens to use resources under the SLA, but can't change the service level themselves. Application services are normally managed by SLA rather than directly by the credit limits on a trade account, so this allows a manager in the client organisation to control access by their users to application services, as well as to the line of credit provided to the organisation by a service provider.