IBM Proposal
January, 2003
Consider a finance application that is exposed as a Web service: BankService. The BankService allows for funds to be transferred from one account to another related account through one of the operations in the defined portType. It is required that in order to transfer more than one million dollars between accounts, that the request be submitted from a kiosk within a bank location and not over a pervasive device. In addition, it may require that the user be authenticated with a biometric device (finger print) in addition to other forms of authentication. In cases where the actual service is being invoked through a set of other front-ending services (e.g., a financePortal service that calls the BankService to invoke the transfer), the context is required to be maintained and made available for end-to-end protection. This will allow for any service down the stream to make decisions based on the context - e.g., entry point, time of day, location of request origination, strength of authentication, original identity who initiated the request (for auditing), etc..
Instead of modelling the web service to handle these information and enforce policies accordingly, it is better to leave the decision to the underlying infrastructure to enforce this. For this to be possible, the security context (and other related context information about the access) must be maintained in an end to end fashion. This context must also be secured such that it cannot be tampered with because critical decisions may rely on the context information.
Thus, the solution to this problem requires a way to distinguish between application level data of a Web service and middleware level data of a Web service. Such data may be both input as well as output of the Web service.
Middleware level data of a Web service interaction is called "context." The previous paragraphs motivate the need to communicate contextual information in addition to application data when using Web services.
Such middleware level information is typically not exposed to the application in the same manner as first-class application data. Instead, language bindings will typically provide mechanism for the necessary context to be "filled in" and "managed" by the middleware.
In general, a context is a typed piece of data. How and when a certain context flows within a given Web service interaction is a property of the specific service. That is, the details of whether context item flows within transport level headers or elsewhere is a binding detail or a policy of the Web service.
We also require that every context be given a globally unique name in the form of an XML qualified name (QName). Having such a mechanism allows specifications such as WS-Transactions to define contexts, give them suitable names and for Web services to indicate that they somehow use that context.
An interaction with a service may involve more than one context, for example, a transaction context and a security context. Furthermore, contexts typically have a lifecycle that may be associated with a particular "session" with the service. That is, during an interaction with some service a certain piece of context may get created by the service provider. The service requestor would then have to use the same value for the context for the duration of that "session" as a way to provide the service provider with the appropriate context. An example of such a session is the ubiquitous HTTP cookie approach for maintaining HTTP sessions.
It is expected that certain common information will be present in all contexts. Similarly, certain domains may define a family of contexts where each context has a common base structure. Thus, it may be useful to define a set of base complex types that contexts may derive from.
It is important to note that context variables will often be used to carry sensitive information. To reduce the possibility of replay and other kinds of attacks, every such context variable must have an expiration property.
Furthermore, contexts could be secured so that they cannot be tampered with; and associated with a nonce and a timestamp that they cannot be replayed. This is important characteristic of a context to ensure that the system makes the right set of decisions based on the context - without worrying about the authenticity of the context data itself.
Contexts are like variables associated with a service interaction. As such they have certain lifecycle properties which must be adhered to. This section defines the lifecycle of context variables of a service.
At the start sequence of interactions Web service, all contexts of that Web service have no value. If some context is required by that service, then the service invoker must fill that context with information obtained elsewhere and send it along with the input message. If a service produces some context, then that value is used to fill in the context, or update it if it already had a value. Once a context has a value, the value is retained within that context until is updated by some produced context or some application action. Thus, contexts act as "state" variables holding state across a sequence of interactions with the service.
We assume that contexts are defined in a service-wide manner. That is, a given context variable is visible across the entire service. Thus, if the result of one operation updates a context value, then any other operations that use the same context must get the updated value. Context value updates are required to be atomic. Thus, contexts act as sychronized, shared variables of the service invoker.
When two parties are engaged in a service invocation, it is necessary to have a common semantic for negotiating what can be exchanged as context during that interaction. In shared-middleware distributed computing infrastructures such as CORBA, it is not necessary for components to describe their middleware managed context data to service requestors as it was "automatically" taken care of by the middleware. However, given Web services' distinguishing characteristic of not assuming any specific middleware implementation at either end of a communication, a service publisher must describe all context data that it consumes and produces. This allows the service requestor to produce and consume such data through some combination of middleware level management and application level management as appropriate for itself.
In the Web services framework, there are at least two environments where contexts may be defined: the first is at the point of defining and describing the service itself. Such contexts would be required for all usages of the service and hence belongs in the WSDL description of the service. The second is via a policy that applies to already deployed services. For example, such a policy may require that the interaction with that service for certain class of users be secured. Let us assume that the protocol for "securing the interaction" require some security context to flow between the requestor and the provider. In that case, the policy effectively introduces additional context that must flow during service interaction.
The following two sections propose concrete mechanisms for introducing context via WSDL and via a policy, respectively.
This section proposes a simple extension to WSDL 1.1 (or 1.2) to add a context description capability. We propose syntax and semantics for:
Note that, unless otherwise specified, all elements in this section are declared in the WSDL namespace as immediate children of the <definitions> element. The use of "ncname" and "qname" are similar to that in WSDL 1.1 - any new declaration always provides an NCName and all references use QNames. Syntax in boldface represents new or modified syntax w.r.t. WSDL 1.1.
A context is a typed piece of data, like a WSDL message part. A context is defined within the <definitions> element of WSDL and refers to a previously defined XML Schema complex type. Note that XSD complex types are used as they are in WSDL- as abstract types not necessarily implying a final XML serialization as messages are exchanged. The final serialization depends completely on the binding given for the context. The syntax for defining a context is as follows:
<context name="ncname" type="qname"/>+
Note that similar to how parts are defined in messages, contexts can be defined using another type system by using an extension attribute instead of "type". Note also that it is possible to declare more then one context for a given service.
We also allow a service description to simply indicate that the service uses a well-known context without actually defining it. The syntax is as follows:
<context ref="qname"/>+
More than one such well-known context may of course be listed. Thus, a WSDL service description may define zero or more contexts and indicate that it uses zero or more well-known contexts by identifying them by their QName.
Once contexts have been defined, it is necessary to indicate when and where a service provides or requires that context. We say a service provides some context if it creates (potentially new) values for that context as a part of the output of an interaction with the service. Similarly, we say a service requires some context if it requires that the indicated context be given to the service along with the WSDL message containing the application level data. Exactly how the context is provided or required by the service (such as SOAP headers or transport headers) is dependent on how the context is bound.
The production and consumption of contexts may be indicated at different levels of granularity. At the lowest level, it may be desired to indicate that certain operations of a portType produce certain context while others produce others. The next level of granularity is the portType level, where all operations of a portType are assumed to have the same required and provided contexts.
Operation-level context is defined using the following modified WSDL syntax:
<portType name="ncname">
<operation name="ncname">+
<input message="qname" contexts="list-of-qnames"/>
<output message="qname" contexts="list-of-qnames"/>
</operation>
</portType>
Note that while the summary syntax above doesn't indicate it, the usual WSDL 1.1 permuntations of <input> and <output> are allowed to create the four styles of operations.
PortType-level context is defined using the following modified WSDL syntax:
<portType name="ncname"
inputContexts="list-of-qnames" outputContexts="list-of-qnames">
<operation name="ncname">+
...
</operation>
</portType>
We of course allow one to combine these declarations. If some contexts are at a portType level, then they can be specified at that level; if additional contexts are only at a per-operation level, then they can be specified at that level.
Note also that the same context can be listed as an inputContext and an outputContext.
Since contexts are defined as part of the abstract description of a service, they need to get bound to a specific protocol that defines how context data is exchanged. Contexts are similar to parts of WSDL messages and get bound similarly. Operation-level and portType-level bindings can be bound easily using the WSDL 1.1 binding approach.
The proposed SOAP binding for contexts carries contexts as SOAP headers. We propose the following syntax:
<soap:headerContext context="qname" element="qname" mustUnderstand="true|false"?
use="literal|encoded" encodingStyle="list-of-nyURI"?/>
The "context" attribute identifies the context that's being bound and a context of that QName must be defined (or referred to) in this service's description. The "element" attribute provides the QName of the header element to create as the serialization of the context value. The "mustUnderstand", "use" and "encodingStyle" attributes have the same semantics as in the <soap:header> element of WSDL 1.1's SOAP binding.
This element can be placed directly within the <binding> element for a portType-level context item or within a <operation> element for an operation level context item:
<binding name="ncname" type="qname">
<soap:binding .../>
<soap:headerContext .../>+
<operation name="ncname">+
<input>
<soap:headerContext .../>+
...
</input> <output
<soap:headerContext .../>+
...
</output </operation>
</binding>
Certain service policies may require that additional context to be exchanged during service interaction. This should be covered in the context of the WS-Policy specification.