Web services security and Java 2 Platform, Enterprise Edition security relationship
This document describes the relationship between Web services security (message level security) and Java 2 Platform, Enterprise Edition (J2EE) platform security.
WAS supports Java Specification Requests (JSR) 101 and JSR 109 (see Developing Web services for more information). These JSRs define Web services for the Java 2 Platform, Enterprise Edition (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 (see Web services security support for more information).
Important:"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)
You can secure Web services using the existing security infrastructure of WAS, J2EE role-based security, and SSL transport level security.
The Web services endpoint 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 endpoint 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 endpoint is not secured with J2EE role-based security and the enterprise bean is secured with J2EE role-based security.
Simple Object Access
In this case, the Web services endpoint 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 endpoint. 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.
See AlsoWeb services security specification- a chronology
Web services security model in WAS
Securing Web services based on WS-Security
Web services security support
Developing Web services based on Web Services for J2EE