Web services security and Java 2 Platform, Enterprise Edition security relationship

This document describes the relationship between Web services security (message level security) and J2EE platform security. Important distinction between V5.x and v6.x applications

Note: The information in this article supports v5.x applications only that are used with WAS v6.x. The information does not apply to v6.0.x applications.

WebSphere Application Server supports Java Specification Requests (JSR) 101 and JSR 109. For more information, see Developing Web services applications. JSRs 101 and 109 define Web services for the J2EE architecture so that you can develop and run Web services on the J2EE component architecture. "Web services security" refers to the "Web services security: SOAP Message Security" specification. For more information, see Web services security support. Important

Note: "Web services security" refers to the "Web services security: SOAP Message Security" specification (see Web services security support for more information).

 

Securing Web services with WAS security

(J2EE role-based security)

We can secure Web services using the existing security infrastructure of WebSphere Application Server, J2EE role-based security, and SSL transport level security. Figure 1. Simple object access protocol message flow using existing security infrastructure of WebSphere Application Server

The Web services port can be secured using J2EE role-based security. The Web services sender sends the basic authentication data using the HTTP header. SSL (HTTPS) can be used to secure the transport. When the WebSphere Application Server receives the SOAP message, the Web container authenticates the user (in this example, user1) and sets the security context for the call. After the security context is set, the SOAP router servlet sends the request to the implementation of the Web services (the implementation can be JavaBeans or enterprise bean files). For enterprise bean implementations, the EJB container performs an authorization check against the identity of user1.

The Web services port also can be secured using the J2EE role. Then, authorization is performed by the Web container before the SOAP request is dispatched to the Web services implementation.

 

Securing Web services with Web services security at the message

level

We can also secure Web services using Web services security at the message level. In this case, one can digitally sign or encrypt a certain part of the message. Web services security also supports security token propagation within the SOAP message. The following scenario assumes that the Web services port is not secured with J2EE role-based security and the enterprise bean is secured with J2EE role-based security. Figure 1. Simple Object Access Protocol message flow using Web services security

In this case, the Web services port is not secured with J2EE role-based security. The Web services engine processes the SOAP message before the client sends the message to the Web services port. The Web services security run time acts on the security constraints, such as digitally signing, encrypting, or generating (and inserting) a security token in the SOAP header. In this case <wsse:UsernameToken> is generated using user1 and the password. On the server-side (receiving), the Web services process the incoming message and Web services security enforces security constraints. This enforcement includes making sure that messages are properly signed, properly encrypted, and decrypted, authenticating the security token, and setting up the security context with the authenticated identity. (In this case, user1 is the authenticated identity.) Finally, the SOAP message is dispatched to the Web services implementation (if the implementation is an enterprise beans file, the EJB container performs an authorization check against user1). SSL also might be used in this scenario.

 

Mixing the two

The second scenario shows that Web services security can complement J2EE role-based security. For example, SSL can be enabled at the transport level to provide a secure channel. Furthermore, if the Web services implementation is an enterprise beans file, one can leverage the EJB role-based authorization by performing authorization checks. Web services security run time leverages the security infrastructure to set the authenticated identity in the security context. The authenticated identity can be used in the downstream call to J2EE resources (or other resource types).

There are subtle consequences of combining the two scenarios. For example, if the HTTP transport is sending basic authentication data with user1 and password in the HTTP header, but <wsse:UsernameToken> with user99 and letmein also is inserted into the SOAP header. In the previous scenarios, there are two authentications performed. One authentication is performed by the Web container for authenticating user1, and the other is performed by Web services security for authenticating user99. The Web services security run time runs after the Web container runs and user99 is the authenticated identity that is set in the security context.

Web services security can also propagate security tokens from the sender to the receiver for SOAP over a Java Message Service (JMS) transport.

 

See Also


Web services security specification-a chronology
Web services security model in WebSphere Application Server

 

Related Tasks


Web services security support
Developing Web services applications