Web Services Security and Java Platform, Enterprise Edition 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.
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.
Important: Web Services Security refers to the Web Services Security: SOAP Message Security specification. For more information, see Web Services Security support.
Secure web services with WAS security (Java EE role-based security)
We can secure web services using the existing security infrastructure of WAS, Java EE role-based security, and SSL transport level security.
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 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 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 Web Services Security at the message level
We can also secure web services using Web Services 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 Web Services 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 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 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 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.
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 specification 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 we must use stateless session beans to implement the web service. For more information about using stateless session beans to implement a web service, read the topics "Implementing web services applications with JAX-WS" or "Implementing web services applications with JAX-RPC," depending on your programming model. Also, read about securing enterprise bean applications. If we develop a web service 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 Web Services 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: