Overview of authentication methods
The Web Services Security implementation for WebSphere Application Server supports the following authentication methods: BasicAuth, LTPA, digital signature, and identity assertion.
Important: There is an important distinction between Version 5.x and Version 6 and later applications. The information supports Version 5.x applications only used with WAS v6.0.x and later. The information does not apply to Version 6 and later applications.
When the WAS 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. We 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:
- BasicAuth
- Digital signature
- Presumed trust
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:
- The downstream server validates the authentication information of the intermediary server.
- 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 required for each authentication method.
| 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>:
|
| 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"/>
We 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 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
Related tasks