14.7 Application Patterns

This section examines two patterns of evolving Web services from existing Web applications.

1. One pattern is the browser-to-server pattern , which wraps an existing application as a service using a SOAP message as the service invocation. The Web server provides a runtime execution container that defines its own security model with policy information derived from a deployment descriptor configured by the Deployer of the Web application (see Section 3.7.3 on page 70). This pattern typically includes a mechanism for associating the identity of the invoking entity ”the Web browser client ”with the executing application instance and allows the application to continue to function as it did before.

   In the J2EE instance, this would manifest itself as the creation of a CSIv2 identity assertion (see Section 3.12 on page 99). A CSIv2 identity assertion uses an implicit trust model in the sense that the client and the server rely on the middleware configuration to ensure that the identity is established within a security context provided by the J2EE environment itself. An advantage of this model is that the runtime maintains the ID-mapping and name -assertion lifetime constraints, whereas mechanisms for maintaining a valid token can be provided by the middleware. A disadvantage is that the model for delegating an identity requires that the delegated application-level identity be the same as the invocation identity of the intermediary and hence the security context. This creates a coupling between the middleware and the application-level delegation logic ”the run-as deployment descriptor element in J2EE ”and another coupling between the middleware and the requirement for the security context to support cascaded delegation, auditing, and nonrepudiation.

2. The second pattern involves rewriting the application with a modular design to create smaller tasks that can be combined in different ways to perform more complicated transactions. Each component is able to externalize its output into a message that the following component can take as input. This pattern uses SOAP messages to trigger each event. The messaging agents and message queues can be built into the runtime server below the application level. Sometimes, the messaging agents become the security-aware part of the runtime and control the flow of information along its path , based on security attributes in the header of the message.

   Sometimes, the security attributes get added into the message structure itself, as is the case with digital signatures. The trust model for this type of messaging relies on the specification of an explicit trust model. In this model, the trust will be explicit , or direct , in the sense that the client and the server rely on coupling the identity information along with the message explicitly and thus do not rely on the underlying security context. This requires that the service handler be able to establish the identity of the caller, based on the WS-Security UsernameToken element, which is specified in the SOAP header, and based on the trust on the entity that created the assertion tokens. Thus, in a direct, or explicit, trust model, an authentication/authorization authority has to be known and digitally sign the assertions at the time of the authentication/authorization event. A certificate associated with the signature can be used to identify the trusted authority and validate the signature. A trusted timestamp is included to indicate the assertion validity period. An advantage of this type of trust model is that the message can pass through multiple intermediaries. Authorization and delegation decisions can be made in a standard way by the intermediaries without modifying the name assertion of the originator of the message request.

   If implemented in an enveloped way, it is also possible to build audit trails capable of asserting evidence of nonrepudiation, as each intermediary could wrap a message with its own name assertion. A disadvantage of this model is that the end point has to do some additional processing to make sure that the originator name assertion is valid both from a trust standpoint and a time standpoint.

Both patterns implement security in the runtime, and both rely on a mapping of an external form of an identity into a runtime interpretation of that identity and into a set of rules about the identity and its capabilities. The differences relate to who does the mapping and whether the information is in an externalized form that can be middleware independent and persistent.