Security model mixture

There can be multiple protocols and channels in the WebSphere® Application Server Version 6 and later programming environments. Each of these applications serve different business needs.

For example, you might access:
  • A Web-based application through the HTTP transport such as a servlet, JavaServer Pages (JSP) file, HTML and so on.
  • An enterprise application through the Remote Method Invocation (RMI) over the Internet Inter-ORB (RMI/IIOP) protocol.
  • A web service application through the SOAP over HTTP, SOAP over the Java™ Message Service (JMS), or SOAP over the RMI/IIOP protocol.

More importantly, web services are often implemented as servlets with a Enterprise JavaBeans (EJB) file. Therefore, you can mix and match the Web Services Security model with the Java Platform, Enterprise Edition (Java EE) security model for web and EJB components. It is intended that web service security complement the Java EE role-based security and the security run time for WebSphere Application Server Version 6 and later.

Web Services Security also can take advantage of the security features in Java EE and the security run time for WebSphere Application Server Version 6 and later. For example, Web Services Security can use the following security features to provide an end-to-end security deployment:
  • Use the local OS, Lightweight Directory Access Protocol (LDAP), and custom user registries for authenticating the username token
  • Propagate the Lightweight Third Party Authentication (LTPA) security token in the SOAP message
  • Use identity assertion
  • Use a trust association interceptor (TAI)
  • Enable security attribute propagation
  • Use Java EE role-based authorization
  • Use a Java Authorization Contract for Containers (JACC) authorization provider, such as Tivoli® Access Manager

The following figure shows that different security protocols are used to send authentication information to the application server. For a web service, you might use either HTTP basic authentication with Secure Sockets Layer (SSL) or a Web Services Security username token with signing and encryption. In the following figure, when identity bob from Web Services Security is authenticated and set as the caller identity of the SOAP message request, the Java EE Enterprise JavaBeans container performs authorization using bob before the call is dispatched to the service implementation, which, in this case, is the enterprise bean.

Security protocol that are used to send authentication information to the Application Server

You can secure a web service using the transport layer security. For example, when you are using SOAP over HTTP, HTTPS can be used to secure the web service. However, transport layer security provides point-to-point security only. This layer of security might be adequate for certain scenarios. However, when the SOAP message must travel through intermediary servers (multi-hop) before it is consumed by the target endpoint, you might use SOAP over the Java Message Service (JMS). The usage scenarios and security requirements dictate how to secure web services. The requirements depend upon the operating environment and the business needs. However, one key advantage of using Web Services Security is that it is transport layer independent; the same Web Services Security constraints can be used for SOAP over HTTP, SOAP over JMS, or SOAP over RMI/IIOP.


Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: March 5, 2017 17:24
File name: cwbs_secmodelmix.html