+

Search Tips   |   Advanced Search

 

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

 

This article describes the relationship between Web services security (message level security) model and the Java 2 Platform, Enterprise Edition (J2EE) security model. It also includes information on J2EE role-based authorization checks.

There is an important distinction between V5.x and V6 and later applications. The information in this article supports V5.x applications only that are used with WebSphere Application Server V6.0.x and later. The information does not apply to Version 6.0.x and later applications.

WAS supports Java Specification Requests (JSR) 101 and JSR 109. 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.

 

Securing Web services with WAS security (J2EE role-based security)

You can secure Web services using the existing security infrastructure of WAS, J2EE role-based security, and SSL transport level security. Figure 1. SOAP 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 WAS 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

You can also secure Web services using Web services security at the message level. In this case, you 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 2. SOAP 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, you 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 JMS transport.

 

J2EE role-based authorization checks

A standard for authorization does not exist for Web services. However, IBM, in conjunction with Microsoft Corporation, jointly published a security white paper road map for Web services called Security in a Web Services World: A Proposed Architecture and Roadmap in which a proposal exists for the WS-Authorization specification. However, the WS-Authorization specification has not been published.

The existing implementation of Web services security is based upon the Web Services for J2EE specification or the JSR-109 specification. The implementation of Web services security leverages the J2EE role-based authorization checks. For conceptual information on role-based authorization, see Role-based authorization. If you develop a Web service that requires method-level authorization checks, then use stateless session beans to implement your Web service. For more information on using stateless session beans to implement a Web service, see Developing a Web service from an enterprise bean and Securing enterprise bean applications. If you develop a Web service that is implemented as a servlet, you can use coarse-grained or URL-based authorization in the Web container. However, in this situation, you cannot use the identity from Web services security for authorization checks. Instead, you can use the identity from the transport. If you use SOAP over HTTP, then the identity is in the HTTP transport.


 

Related concepts


Web services security specification—a chronology
Web services security model in WAS
Role-based authorization

 

Related tasks


Developing Web services applications from enterprise beans
Securing enterprise bean applications
Securing Web services for V5.x applications based on WS-Security

 

Related Reference


Web services security support