Authentication method overview

[Version 5 only]

 

Authentication method overview

The Web services security implementation for WebSphere Application Server supports the following authentication methods: BasicAuth , Lightweight Third Party Authentication (LTPA), digital signature, and identity assertion.

Important distinction between Version 5.x and Version 6 applications

Note: The information in this article supports version 5.x applications only that are used with WebSphere Application Server Version 6. The information does not apply to version 6 applications.

When the WebSphere Application Server is configured to use the BasicAuth authentication method, the sender attaches the LTPA token as a BinarySecurityToken from the current security context or from basic authentication data configuration in the binding file in the SOAP message header. The Web services security message receiver authenticates the sender by validating the user name and password against the configured user registry. With the LTPA method, the sender attaches the LTPA BinarySecurityToken it previously received in the SOAP message header. The receiver authenticates the sender by validating the LTPA token and the token expiration time. With the Digital Signature authentication method, the sender attaches a BinarySecurityToken from a X509 certificate to the Web services security message header along with a digital signature of the message body, time stamp, security token, or any combination of the three. The receiver authenticates the sender by verifying the validity of the X.509 certificate and the digital signature using the public key from the verified certificate.

The identity assertion authentication method is different from the other three authentication methods. This method establishes the security credential of the sender based on the trust relationship. You can use the identity assertion authentication method, for example, when an intermediary server must invoke a service from a downstream server on behalf of the client, but does not have the client authentication information. The intermediary server might establish a trust relationship with the downstream server and then assert the client identity to the same downstream server. Web Services Security supports the following trust modes:

When you use the BasicAuth and digital signature trust modes, the intermediary server passes its own authentication information to the downstream server for authentication. The presumed trust mode establishes a trust relationship using some external mechanism. For example, the intermediary server might pass SOAP messages through a Secure Socket Layers (SSL) connection with the downstream server and transport layer client certificate authentication. The Web services security implementation for WebSphere Application Server validates the trust relationship by following this procedure:

  1. The downstream server validates the authentication information of the intermediary server.

  2. The downstream server verifies whether the authenticated intermediary server is authorized for identity assertion. For example, the intermediary server must be in the trust list for the downstream server.

The client identity might be represented by a name string, a distinguished name (DN), or an X.509 certificate. The client identity is attached in the Web services security message in a UsernameToken with just a user name, DN, or in a BinarySecurityToken of a certificate. The following table summarizes the type of security token that is required for each authentication method.

Table 1. Authentication methods and their security tokens
Authentication method Security token
BasicAuth BasicAuth requires <wsse:UsernameToken> with <wsse:Username> and <wsse:Password>.
Signature Signature requires <ds:Signature> and <wsse:BinarySecurityToken>.
IDAssertion IDAssertion requires <wsse:UsernameToken> with <wsse:Username> or <wsse:BinarySecurityToken> with a

X.509 certificate for client identity depending on <idType>. This method also requires other security tokens according to the <trustMode>:

  • If the <trustMode> is BasicAuth ,

    IDAssertion requires <wsse:UsernameToken> with <wsse:Username> and <wsse:Password>.

  • If the <trustMode> is Signature ,

    IDAssertion requires <wsse:BinarySecurityToken>.

LTPA LTPA requires <wsse:BinarySecurityToken> with an LTPA token.
A Web service can support multiple authentication methods simultaneously. The receiver side of the Web services deployment descriptor can specify all the authentication methods that are supported in the ibm-webservices-ext.xmi XML file. The Web services receiver-side, as shown in the following example, is configured to accept all the authentication methods described previously: 

<loginConfig xmi:id="LoginConfig_1052760331326">
      <authMethods xmi:id="AuthMethod_1052760331326" text="BasicAuth"/>
      <authMethods xmi:id="AuthMethod_1052760331327" text="IDAssertion"/>
      <authMethods xmi:id="AuthMethod_1052760331336" text="Signature"/>
      <authMethods xmi:id="AuthMethod_1052760331337" text="LTPA"/>
</loginConfig>
<idAssertion xmi:id="IDAssertion_1052760331336" idType="Username" trustMode="Signature"/>
You can define only one authentication method in the sender-side Web services deployment descriptor. A Web service client can use any of the authentication methods that are supported by the particular Web services application. The following example illustrates an identity assertion authentication method configuration in the ibm-webservicesclient-ext.xmi deployment descriptor extension of the Web service client:
<loginConfig xmi:id="LoginConfig_1051555852697">
      <authMethods xmi:id="AuthMethod_1051555852698" text="IDAssertion"/>
</loginConfig>
<idAssertion xmi:id="IDAssertion_1051555852697" idType="Username" trustMode="Signature"/>
As shown in the previous example, the client identity type is Username and the trust mode is digital signature.

Figure 1. Security token generation and validation

The sender security handler invokes the handle() method of an implementation of the javax.security.auth.callback.CallbackHandler interface. The javax.security.auth.callback.CallbackHandler interface creates the security token and passes it back to the sender security handler. The sender security handler constructs the security token based on the authentication information in the callback array and inserts the security token into the
Web services security message header.

The receiver security handler compares the token type in the message header with the expected token types configured in the deployment descriptor. If none of the expected token types are found in the Web services security header of the SOAP message, the request is rejected with a SOAP fault exception. Otherwise, the token type is used to map to a Java Authentication and Authorization Service (JAAS) login configuration for validating the token. If the authentication is successful, a JAAS Subject is created and associated with the running thread. Otherwise, the request is rejected with a SOAP fault exception.

Related concepts
BasicAuth authentication method
Lightweight Third Party Authentication
XML digital signature
Identity assertion
Username token element
Binary security token

Related tasks
Securing Web services for version 5.x applications using basicauth authentication
Securing Web services for version 5.x applications using identity assertion authentication
Securing Web services for version 5.x applications using signature authentication
Securing Web services for version 5.x applications using a pluggable token