50 lines
5.2 KiB
HTML
50 lines
5.2 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<html>
|
|
<head>
|
|
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
|
|
<LINK rel="stylesheet" type="text/css" href="../../../rzahg/ic.css">
|
|
|
|
<title>Web services security and J2EE role-based security</title>
|
|
</head>
|
|
|
|
<BODY>
|
|
<!-- Java sync-link -->
|
|
<SCRIPT LANGUAGE="Javascript" SRC="../../../rzahg/synch.js" TYPE="text/javascript"></SCRIPT>
|
|
|
|
<h5><a name="wssecovj2ee"></a>Web services security and J2EE role-based security</h5>
|
|
|
|
<p>WebSphere Application Server - Express supports JSR 101 and JSR 109. These JSRs define Web services for Java 2 Platform Enterprise Edition (J2EE) architecture so you can develop and run Web services on the J2EE component architecture. This architecture allows Web services to leverage the infrastructure of the J2EE platform like the J2EE deployment model, scalability, security, transaction, and other quality of services provided by the J2EE platform. This document describes the relationship between Web services security (message level security) and J2EE platform security.</p>
|
|
|
|
<p><strong>WebSphere Application Server - Express security (J2EE role-based security)</strong></p>
|
|
|
|
<p>You can secure Web services using the existing security infrastructure of WebSphere Application Server - Express, J2EE role-based security, and SSL transport level security.</p>
|
|
|
|
<p><strong>Figure 1: Simple object access protocol message flow through the existing security infrastructure of WebSphere Application Server - Express</strong></p>
|
|
|
|
<p><img src="rzamy519.gif" width="540" height="441" alt="Simple object access protocol message flow through the existing security infrastructure of WebSphere Application Server - Express"></p>
|
|
|
|
<p>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 WebSphere Application Server - Express receives the SOAP message, the Web container authenticates the user (in this example, user1) and sets the security context for the call. After this is complete, the SOAP router servlet sends the request to the implementation of the Web services (the implementation can be a JavaBean).</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p><strong>Web services security</strong></p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p><strong>Figure 2: SOAP message flow and Web services security</strong></p>
|
|
<p><img src="rzamy518.gif" width="540" height="441" alt="SOAP message flow and Web services security"></p>
|
|
|
|
<p>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 with the user ID (user1) and password.</p>
|
|
|
|
<p>On the server-side (receiving), the Web service processes the incoming message and Web services security enforces security constraints. This includes ensuring 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. SSL also may be used in this scenario.</p>
|
|
|
|
<p><strong>Web services security and J2EE role-based security</strong></p>
|
|
|
|
<p>The previous scenario shows that Web services security can compliment J2EE role-based security. For example, SSL can be enabled at the transport level to provide a secure channel. The Web services security run time uses the security infrastructure in order 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).</p>
|
|
|
|
<p>There are subtle consequences of combining the two scenarios. For example, the HTTP transport is sending basic authentication data with the user ID (user1) and password in the HTTP header, but <wsse:UsernameToken> with a different user ID (user99) and password is also inserted into the SOAP header. In the previous scenarios, there are two authentications performed. One is performed by Web container for authenticating user1, and the other is performed by Web services security for authenticating user99. Web services security run time runs after Web container authentication runs, so user99 is the authenticated identity that is set in the security context.</p>
|
|
|
|
</body>
|
|
</html>
|
|
|