WS-Security and Java EE security relationship
This article describes the relationship between Web services security (message level security) model and the Java EE security model. It also includes information on Java EE role-based authorization checks.
There is an important distinction between V 5.x and V6 and later applications. The information in this article supports V5.x applications only that are used with WAS V6.0.x and later. The information does not apply to V6.0.x and later applications.
WAS supports Java Specification Requests (JSR) 101 and JSR 109. JSRs 101 and 109 define Web services for the Java EE architecture so that we can develop and run Web services on the Java EE component architecture.
WS-Security refers to the WS-Security: SOAP Message Security specification. For more information, see WS-Security support.
Secure Web services with WebSphere Application WAS security (Java EE role-based security)
You can secure Web services using the existing security infrastructure of WAS, Java EE role-based security, and SSL) TLS. Figure 1. SOAP message flow using existing security infrastructure
The Web services port can be secured using Java EE 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 Java Beansor 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 Java EE role. Then, authorization is performed by the Web container before the SOAP request is dispatched to the Web services implementation.
Secure Web services with WS-Security at the message level
We can also secure Web services using WS-Security at the message level. In this case, we 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 Java EE role-based security and the enterprise bean is secured with Java EE role-based security. Figure 2. SOAP message flow using WS-Security
In this case, the Web services port is not secured with Java EE role-based security. The Web services engine processes the SOAP message before the client sends the message to the Web services port. The WS-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 EJBs container performs an authorization check against user1). SSL also might be used in this scenario.
Mixing the two
The second scenario shows that WS-Security can complement Java EE 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, we 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 Java EE 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 WS-Security for authenticating user99. The WS-Security run time runs after the Web container runs and user99 is the authenticated identity that is set in the security context.
WS-Security can also propagate security tokens from the sender to the receiver for SOAP over a JMS transport.
Java EE 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 spec has not been published.
The existing implementation of Web services security is based upon the Web Services for Java EE specification or the Java Specification Requirements (JSR) 109 specification. The implementation of Web services security leverages the Java EE role-based authorization checks. For conceptual information, read about role-based authorization. If we develop a Web service that requires method-level authorization checks, then use stateless session beans to implement the Web service.
See about using stateless session beans to implement a Web service, read the topics "Implement Web services applications with JAX-WS" or
"Implement Web services applications with JAX-RPC," depending on your model. Also, read about securing enterprise bean applications. If we develop a Web service that is implemented as a servlet, we can use coarse-grained or URL-based authorization in the Web container. However, in this situation, we cannot use the identity from WS-Security for authorization checks. Instead, we can use the identity from the transport. If we use SOAP over HTTP, then the identity is in the HTTP transport.
Related concepts
WS-Security specification—a chronology
WS-Security model in WAS
Role-based authorization
Related tasks
Implement Web services applications with JAX-WS
Implement Web services applications with JAX-RPC
Secure enterprise bean applications
Secure Web services for V5.x applications based on WS-Security
Related
WS-Security support