7.6 Web Services Security Patterns

Most of the security technologies depicted in this chapter may not provide a complete solution to many complex business problems. They need to be combined and implemented together in order to be contextual to different business issues. Here are some Web Services security design patterns. For each, we describe a scenario where the design pattern may be applied, followed by some discussion of how different Web Services security technologies can be implemented to provide complete business solutions.

7.6.1 Single Sign-on Pattern

Context

Single Sign-on has been a requirement for many enterprises . Cross-domain Single Sign-on is one of the major challenges of Web Services security. Under a B2B cross-enterprise integration scenario (such as automated dispute management and exceptions management), a trading partner's server may need to access different servers from multiple trading partners ' infrastructure. Architects and developers need a vendor-independent framework to perform cross-domain Single Sign-on with login once for each application.

Each of the current security specifications and initiatives, such as Liberty and Security Assertion Markup Language (SAML), can only address certain aspects of cross-domain Single Sign-on. Liberty specification version 1.1 defines an authentication mechanism using a federated identity service model. It extends existing SAML schema for authentication entities, but does not address authorization, access control, or policies. On the other hand, SAML does not validate the identity or credentials presented during the authentication process.

This security design pattern will address the requirement of cross-domain Single Sign-on. SAML assertions can be encapsulated in the XML message payload just like a security token. Upon successful authentication using the Liberty solution, the client will establish a trust with different servers. The system can then pass SAML assertions across trading partners' servers using the existing SAML specification. This will provide a trusted environment to support cross-domain Single Sign-on from authentication and authorization to policies.

Problem

Users who have access to two or more different Service Providers have different login ids and passwords. As the Service Providers are using different platforms and technologies for the applications, users usually need to log in once for each Service Provider's application. If users need to switch from one application to another across different Service Providers (that is, cross-domain), they have to log in twice.

There are security products that support cross-domain Single Sign-on, but most of them require an affiliate agent (proprietary plug-in to the Web Server and/or Application Server that stores session cookies to enable Single Sign-on). Most Service Providers do not accept "foreign" (not their own domain or application systems) security modules or plug-ins from their trading partners to be installed in their application infrastructure because this may expose them to unknown security risks.

Forces

The level of security trust (the environment and level of security protection where the Service Requester may be operating) between the Service Requester and Service Providers varies, and it is difficult to agree on a common security standard.

It may be not viable to install an affiliate agent to all trading partners' production environments to achieve Single Sign-on, as each trading partner may have different security requirements.

There may be considerable security integration costs, if a vendor-specific Single Sign-on product is used.

Solution

It is recommended to adopt the Open Standards security standards SAML and Liberty to meet Single Sign-on requirements. They do not require installing any proprietary affiliate agent on the trading partner's site.

Figure 7-25 depicts what service components need to be built in order to implement cross-domain Single Sign-on. A Service Requester is a subscriber to the user community who provides online shopping and business services in a portal service. There are two different Service Providers supplying the online shopping and business services, each of which has a different system infrastructure (or different domains).

Figure 7-25. Single Sign-on Pattern

In Figure 7-25, a common security domain needs to be defined to enclose the Service Requester and all the associated Service Providers (trading partners). This requires the use of Identity Server (Identity Provider that centrally authenticates for the Service Requester and redirects to the Service Providers and/or Identity Providers). The physical Identity Server may reside in an external Service Provider that provides identity management services, or in the Service Requester's system environment.

Each of the system resources (for example, Application Server, Messaging Hub) will make use of User Agents (security agents that can intercept and respond to Liberty or SAML assertion requests ). User Agents that are compliant with Liberty and SAML specifications can be implemented using Liberty-enabled or SAML-enabled development toolkits (such as Sun ONE Identity Server http://www.sun.com/software/products/identity_srvr/home_identity.html ). The Service Requester needs to only log in once using a Single Sign-on User Agent. An authentication assertion request will be redirected to the Identity Server. Upon successful authentication, session information will be stored as server cookies in the Common Domain. If the Service Requester needs to access any applications or resources, whether in the Business Tier or in the Resource Tier , the User Agents will create Attribute Assertion or Authorization Assertion requests. It is also recommended to use the XML Access Control Markup Language (XACML) to express policies for information access (refer to http://www.oasis-open.org/ committees /xacml/ for details). Upon the successful processing of these assertions, the Service Requester can access and retrieve information according to the policies set for the entitled access rights and roles.

The Common Domain processes different assertion requests that are processed in each domain. Thus, it doesn't matter if the two domains are using different system architecture; the Identity Server can support Single Sign-on, provided that the User Agents deployed in each resource and in each tier are Liberty- and/or SAML-compliant. Refer to Figure 7-25 for more details.

There are some differences between the Liberty and the SAML approach in implementing Single Sign-on. You can use the SAML approach to implement cross-domain Single Sign-on without using Liberty. However, this will not address identity management issues, such as the authenticity of the Service Requester, or mobile/wireless support for SAML clients . On the other hand, the current Liberty specification version 1.1 does not support Authorization Assertion yet. Thus, it would be a good combination to use Liberty for identity management and Authentication Assertion while using SAML for Authorization Assertion and XACML for Policy Management. The Service Requester can also make use of an external Trust Authority to provide and administer user credentials (for example, digital certificates or key management), instead of implementing PKI or certificate management solutions within its operating environment. Please also refer to the sections in this chapter on Liberty, SAML, and XML Key Management Specification (XKMS) for details.

Figure 7-26 elaborates the details of the cross-domain Single Sign-on process. Under the hybrid security environment, after the Service Requester provides user credentials for Single Sign-on, the Identity Server will redirect authentication to the Identity Provider or Service Provider in Liberty protocol. Upon the successful processing of the Authentication Assertion request, the Service Requester will be granted sign-on to the common security domain. If the Service Requester makes an application request to access or update a system resource, an Authorization Assertion request will be created. The Policy Management module (for example, Policy Server) will forward the user access rights information to the Policy Decision Point (PDP), which will relate the user access rights information with the Authorization Assertion request. The application request will be also forwarded to Policy Enforcement Point (PEP). The PEP, once it has user access rights and policies from the Policy Management module, will process the Authorization Assertion request.

Figure 7-26. Single Sign-on Pattern With Policy Management Details

Liberty specification version 1.1 has depicted the interaction and process between the User Agent, Service Provider, and Identity Provider in detail. The following sequence diagrams recapitulate the detailed processes from "Liberty Bindings and Profiles Specification." ( http://www.projectliberty.org/ specs /liberty-architecture-bindings-profiles-v1.1.pdf ).

Figure 7-27 depicts the details of Single Sign-on activities in a sequence diagram. When the Service Requester logs in, the Single Sign-on User Agent will issue an HTTP request for authentication to the Service Provider (in this example, Domain 1). The Service Provider obtains the Identity Provider Id, which is the Identity Server in the Common Domain. The Service Provider will then respond to the User Agent's authentication request with the Identity Provider Id. The User Agent will then redirect the authentication request to the Identity Provider, which is the Identity Server of the Common Domain.

Figure 7-27. Single Sign-on Sequence Diagram

Upon receiving the authentication request from the User Agent, the Identity Provider processes the request and returns with an authentication request response and an artifact. The User Agent now can send an Authentication Assertion request with the artifact to the Service Provider, which will send an HTTP request with the artifact to the Identity Provider. The Identity Provider will then return with an Authentication Assertion request response to the Service Provider. The Service Provider will process the response and return the result (for example, authentication completed and grant access) to the User Agent. A Common Domain cookie may be created (refer to Figure 7-28 for details).

Figure 7-28. Common Domain Cookie Management Sequence Diagram

You can create Common Domain cookies to track the Identity Provider ids allowed in the Common Domain. Figure 7-28 elaborates the details of how to create a Common Domain cookie in a sequence diagram. Upon the successful processing of the Authentication Assertion requests, the Identity Provider redirects the User Agent to the cookie-writing service. The User Agent then accesses the cookie-writing service URL. The Common Domain cookie-writing service (implemented in the Identity Server) processes the request to write cookies and redirects to the Identity Provider Return URL upon completion of the cookie-writing service. Then the User Agent can access the Identity Provider Return URL. For details, please refer to "Liberty Bindings and Profiles Specification." ( http://www.projectliberty.org/specs/liberty-architecture-bindings-profiles-v1.1.pdf ).

Benefits

This pattern is intended for cross-domain Single Sign-on. It also works for Single Sign-on within the same domain because the Identity Server for the cross-domain scenario manages the Authentication Assertion the same way as in the cross-domain scenario. Achieving Single Sign-on can improve the user experience and customer expectations, as well as reduce the internal system or B2B integration cost.

The proposed solution does not require a proprietary affiliate agent and is compliant with Liberty, SAML, and XACML where architects and developers can select a wider choice of vendor products for implementation.

Risks

Many security specifications and standards are still quickly evolving to add more functionality and features. Liberty specification version 1.1 does not cover authorization, but it may cover authorization and policies in the future releases. If it incorporates SAML Authorization Assertion and XACML Policy Management in the future, architects and developers will be able to use Liberty alone to address the previously mentioned Single Sign-on requirements. The new WS-Security roadmap proposed by IBM, Microsoft, and VeriSign includes similar federation and Policy Management specifications. The existence of similar and competing Web Services security standards and specifications may create industry confusion.

Example

Membership Award Service

The credit card business units of commercial banks that need to provide online membership award services to corporate card customers may require providing Single Sign-on to bank account services (such as credit card account balance and online statements) or membership award redemption from airlines, hotels, and car rental companies. Different trading partners of the commercial bank run different application architectures and do not want to install a proprietary affiliate agent to enable Single Sign-on. Using Liberty-based Identity Server, the commercial bank can enable online corporate customers to sign on once to all membership award service providers. Please also refer to the sample business case in Chapter 2, The Web Services Phenomenon and Emerging Trends.

7.6.2 Messaging Transport Pattern

Context

Early pilots of Web Services applications usually focus on the technology Proof of Concept. Very often, architects and developers do not incorporate any security design in the SOAP message or in the data transport layer. This is because Web Services security for SOAP messaging is still evolving, and there is no reference implementation available yet. In some cases, architects and developers have incorporated the security processing logic in the business logic to provide application security.

Most architects and developers understand that Web Services applications need to secure both the messaging transport and the message contents. The current Web Services security specifications (such as WS-Security http://www.oasis-open.org/committees/wss/documents/WSS-SOAPMessageSecurity-11-0303.pdf ) describe how the message transport can be secured. Since OASIS has begun to take over the work of Web Serv-ices security, there are a few vendor tools that support message-level and data transport layer security for Web Services applications. It is important for architects and developers to be aware of the use of appropriate vendor tools to add message-level and data transport layer security to Web Services applications.

Problem

Many architects and developers embed security business logic into application programs. Thus, when architects and developers need to upgrade the security business logic to a new version or to migrate to a new security standard, they have to modify and retest the application programs.

Tightly coupling the security and application program business logic requires developers to have an in-depth understanding of the security protocols and implementation knowledge.

Force

Many financial services applications require data and message encryption. Developers usually incorporate security-processing logic into the application business logic. Once they make changes to the security-processing standards, considerable effort and impact is required to retrofit changes to all application changes.

The provision of message transport via encryption and digital signature adds performance overhead.

Solution

Web Services security specifications such as WS-Security, XML Encryption, and XML Signature provide guidelines on how to protect the messaging transport layer. Developers can choose to embed the security processing logic (for example, encrypting and decrypting ) into the application business logic or decouple the messaging transport from the application business logic.

Figure 7-29 depicts a security pattern where architects and developers decouple the security processing logic (that is, messaging transport security) from the application business logic. Both the consumer (SOAP client) and the Service Provider (SOAP server) should encrypt the business transactions in SOAP messages with XML Encryption and sign them with a digital signature (messaging security). There are SOAP appliances or WS-Security plug-ins for SOAP servers that provide the messaging security without adding the security processing logic in the business logic. The SOAP messages should also be sent over secure data transport such as HTTPS (data transport layer security). Both XML Encryption and XML Signature are used by the WS-Security specification. This allows application business logic to focus on the application processing flow and enables more options to secure the messaging transport based on different costs (for example, operating overheads of encryption and decryption by the application) and benefits (for example, ease of scaling the Web Services appliances that handle the XML message encryption). Architects and developers can also easily migrate to a more cost-effective messaging transport solution over time without impacting the application business logic.

Figure 7-29. Decoupling Messaging Transport From Application Business Logic

Here are some examples of technology options to decouple messaging transport security from the applications:

Web Services Appliances. There are appliance products that provide XML encryption and decryption, such as Westbridge Technology's ( http://www.westbridgetech.com ). These appliance products, which are usually configured with higher CPU clock speed and encryption hardware devices, are able to use a previously assigned digital certificate (key pairs) to encrypt and decrypt SOAP messages, and thus off-load the performance overhead of the Application Server.

Secure Messaging Provider Class. There are message provider classes, such as VeriSign's Trust Service Integration Kit, that are designed to provide secure messaging using XML Encryption and XML Signature. They are designed to be the message provider (for example, JAXM message provider) so that the application business logic does not need to cater for the details of message encryption, message decryption, and digital signature.

Risk

The performance overhead of encrypting and decrypting data contents may become a considerable operating cost to the applications. There are different options to address the requirements, such as the use of Web Services appliances to off-load the processing overhead from the applications in a Trust Domain.

Example

Apache Axis provides an example of this Message Transport pattern by implementing a client-signing handler for SOAP messaging security with a digital signature. Refer to the sample code under %Axis%\samples\security .

On the accompanying CD-ROM, the /opt/provider-tsik subdirectory contains some more examples of the demo code of Secure Messaging Provider Class. Refer to Chapter 8, Web Services in Action Case Study, for more design details.