Patterns: Implementing Self-Service in an SOA Environment

354 Patterns: Implementing Self-Service in an SOA Environment

layer; for example, in a servlet acting as Web service implementation, or

by using a redundantly configured EJB session facade.

– A stateless request-style Web service instance can be pooled and

load-balanced because it is a Java object in the JVM of the application

server.

– Failover is also supported for request-style Web services.

– If session style is used, scalability is best. However, the Web service

implementation class must be serializable and small.

– If application style is used, load balancing is not an issue, because there is

only one instance whose lifetime is identical to the one of the application

server hosting it.

򐂰 Other Quality of Service considerations

– Clearly define and document achievable QoS standards or requirements.

– Service providers should try to make key measurements available online.

– Use existing standards or proposed specifications as design guidelines.

10.8.1 Security considerations for Web services

Web services security is one of the bigger challenges in implementing Web

services-based systems. With WebSphere Application Server V6, you have the

following options for securing Web services:

򐂰 Message-level security using Web services security (WS-Security)

򐂰 Transport-level security using TLS/SSL

Figure 10-40 provides an overview of Web services security.

Chapter 10. Web services scenario 355

Figure 10-40 Securing Web services

For a full discussion of Web services security and implementation examples, see

WebSphere Version 6 Web Services Handbook Development and Deployment,

SG24-6461.

WS-Security

The WS-Security specification defines message-level security that provides for

message content integrity and confidentiality. Unlike SSL, WS-Security can

provide end-to-end message-level security. This means that the message

security can be protected even if the message goes through multiple services,

called intermediaries. WS-Security is independent of the transport layer protocol

and can be used for any Web service binding (for example, HTTP, SOAP, RMI).

Figure 10-41 End-to-end message-level security

WebSphere Application Server Version 6.0 supports the WS-Security 2004

specification and two token profiles (UsernameToken 1.0, X.509 Certificate

Securing

Web Services

Authentication

example: user

name/password

Integrity

message

signature

Message-level security

(WS-Security)

Confidentiality

message

encryption

Transport-level security

(TLS/SSL)

encrypt the message stream

(HTTPS for HTTP)

Web service

client

Web service

server

Security Context

Intermediary

356 Patterns: Implementing Self-Service in an SOA Environment

Token 1.0). The level of the security specification supported in WebSphere

Application Server Version 6 is above these specifications, with the described

changes in the OASIS erratas:

򐂰 Web Services Security: SOAP Message: Errata 1.0

http://www.oasis-open.org/committees/download.php/9292/oasis-200401-wss-soa

p-message-security-1%200-errata-003.pdf

򐂰 Web Services Security: UsernameToken Profile: Errata 1.0

http://www.oasis-open.org/committees/download.php/9290/oasis-200401-wss-use

rname-token-profile-1.0-errata-003.pdf

򐂰 Web Services Security: X.509 Token Profile: Errata 1.0

http://www.oasis-open.org/committees/download.php/9287/oasis-200401-x509-to

ken-profile-1.0-errata-003.pdf

Here are some simple guidelines as to when WS-Security should be used:

򐂰 Multiple parts of message can be secured in different ways.

You can apply multiple security requirements, such as integrity on the

security token (user ID and password) and confidentiality on the SOAP body.

򐂰 Intermediaries can be used.

End-to-end message-level security can be provided through any number of

intermediaries.

򐂰 Non-HTTP transport protocol is used.

WS-Security works across multiple transports (also change of transport

protocol) and is independent of the underlying transport protocol.

Chapter 10. Web services scenario 357

򐂰 User authentication is possible.

Authentication of multiple party identities is possible.

WS-Security represents only one of the layers in a complex, secure Web

services solution design. A more general security model is required to cover

other security aspects, such as logging and non-repudiation. The definition of

those requirements is defined in a common Web services security model

framework. For more information, see:

򐂰 Security in a Web Services World: A Proposed Architecture and Roadmap,

proposed by IBM and Microsoft.

http://www-106.ibm.com/developerworks/webservices/library/ws-secmap/

Transport-level security

To secure HTTP, transport-level security can be applied. Transport-level

security

is a well-known and often used mechanism to secure HTTP Internet and

intranet communications. Transport-level security is based on Secure Sockets

Layer (SSL) or Transport Layer Security (TLS) that runs beneath HTTP.

HTTPS allows client-side and server-side authentication through certificates,

which have been either self-signed or signed by a certification agency.

For Web services bound to the HTTP protocol, HTTPS/SSL can be applied in

combination with message-level security (WS-Security).

Unlike message-level security, HTTPS encrypts the entire HTTP data packet.

There is no option to apply security selectively on certain parts of the message.

SSL and TLS provide security features including authentication, data protection,

and cryptographic token support for secure HTTP connections.

SOAP/HTTP transport-level security

Although HTTPS does not cover all aspects of a general security framework, it

provides a security level regarding party identification and authentication,

message integrity, and confidentiality. It does not provide authentication,

auditing, and non-repudiation. SSL cannot be applied to other protocols, such as

JMS. To run HTTPS, the Web service port address must be in the form https://.

Even with the WS-Security specification, SSL should be considered when

thinking about Web services security. Using SSL, a point-to-point security can be

achieved.