Overview of authentication methods
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.
When the WebSphere Application Server is configured to use the BasicAuth authentication method, the sender attaches the Lightweight Third Party Authentication (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.
- 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 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 that is 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. |
<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"/>
<loginConfig xmi:id="LoginConfig_1051555852697">
<authMethods xmi:id="AuthMethod_1051555852698" text="IDAssertion"/>
</loginConfig>
<idAssertion xmi:id="IDAssertion_1051555852697" idType="Username" trustMode="Signature"/>
Username
and the trust mode is digital signature.
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.