Login mappings
Login mappings, found in the ibm-webservices-bnd.xmi Extended
Markup Language (XML) file, contains a mapping configuration. This mapping
configuration defines how the Web services security handler maps the token <ValueType> element that is contained within the
security token extracted from the message header, to the corresponding authentication
method. The token <ValueType> element is
contained within the security token extracted from a SOAP message header.
The sender-side Web services security handler generates and attaches security
tokens based on the <AuthMethods> element that is specified in the deployment
descriptor. For example, if the authentication method is BasicAuth,
the sender-side security handler generates and attaches UsernameToken (with
both user name and password) to the SOAP message header. The Web services
security run time uses the Java Authentication and Authorization Service (JAAS) javax.security.auth.callback.CallbackHandler
interface as a security provider to generate security tokens on the client
side (or when Web services is acting as client).
The sender security handler invokes the handle() method
of a javax.security.auth.callback.CallbackHandler interface
implementation. This implementation creates the security token and passes
the token back to the sender security handler. The senders security handler
constructs the security token based on the authentication information in the
callback array. The security handler then inserts the security token into
the Web Services Security message header.
The CallbackHandler interface implementation that you use to generate the
required security token is defined in the <loginBinding> element in the ibm-webservicesclient-bnd.xmi Web
services security binding file. For example,
<loginBinding xmi:id="LoginBinding_1052760331526" authMethod="BasicAuth"
callbackHandler="com.ibm.wsspi.wssecurity.auth.callback.StdinPromptCallbackHandler"/>
The <loginBinding> element associates
the com.ibm.wsspi.wssecurity.auth.callback.StdinPromptCallbackHandler interface
with the BasicAuth authentication method. WebSphere
Application Server provides the following set of CallbackHandler interface
implementations you can use to create various security token types:
- com.ibm.wsspi.wssecurity.auth.callback.GUIPromptCallbackHandler
- If there is no basic authentication data defined in the login binding
information (this information is not the same as the HTTP basic authentication
information), the previous token type prompts for user name and password through
a login panel. The implementation uses the basic authentication data defined
in the login binding. Use this CallbackHandler with
the BasicAuth authentication method. Do not use this CallbackHandler implementation on the server because it
prompts you for login binding information.
- com.ibm.wsspi.wssecurity.auth.callback.StdinPromptCallbackHandler
- If basic authentication data is not defined in the login binding (this
information is not the same as the HTTP basic authentication information),
the implementation prompts for the user name and password using standard in
(stdin). The implementation uses the basic authentication data defined in
the login binding. Use this CallbackHandler implementation
with the BasicAuth authentication method. Do not use
this CallbackHandler implementation on the server
because it prompts you for login binding information.
- com.ibm.wsspi.wssecurity.auth.callback.NonPromptCallbackHandler
- This CallbackHandler implementation does not prompt.
Rather, it uses the basic authentication data defined in the login binding
(this information is not the same as the HTTP basic authentication information).
This CallbackHandler implementation is meant for use
with the BasicAuth authentication method. You must
define the basic authentication data in the login binding information for
this CallbackHandler implementation. You can use this
implementation when Web services is running as a client and needs to send
basic authentication (<wsse:UsernameToken>) to the downstream call.
- com.ibm.wsspi.wssecurity.auth.callback.LTPATokenCallbackHandler
- The CallbackHandler generates Lightweight Third
Party Authentication (LTPA) tokens from the run as JAAS
Subject (invocation Subject) of the current WebSphere Application Server security
context. However, if basic authentication data is defined in the login binding
information (not the HTTP basic authentication information), the implementation
uses the basic authentication data and LTPA token generated. The Token
Type URI and Token Type Local Name values must be defined in the
login binding information for this CallbackHandler implementation.
The token value type is used to validate the token to the request sender and
request receiver binding configuration. The Web services security run time
inserts the LTPA token as a binary security token (<wsse:BinarySecurityToken>)
into the message SOAP header. The value type is mandatory. (See LTPA for more information). Use this CallbackHandler implementation
with the LTPA authentication method.
Figure 1 shows the sender security handler in the request sender message
process.
Request sender SOAP message process
You can configure the receiver-side security server to support multiple
authentication methods and multiple types of security tokens. The following
steps describe the request sender SOAP message process:
- After receiving a message, the receiver Web services security handler
compares the token type (in the message header) with the expected token types
configured in the deployment descriptor.
- The Web services security handler extracts the security token form the
message header and maps the token <ValueType> element
to the corresponding authentication method. The mapping configuration is defined
in the <loginMappings> element in the ibm-webservices-bnd.xmi XML
file. For example:
<loginMappings xmi:id="LoginMapping_1051977980074" authMethod="LTPA"
configName="WSLogin">
<callbackHandlerFactory xmi:id="CallbackHandlerFactory_1051977980081"
classname="com.ibm.wsspi.wssecurity.auth.callback.WSCallbackHandlerFactoryImpl"/>
<tokenValueType xmi:id="TokenValueType_1051977980081"
uri="http://www.ibm.com/websphere/appserver/tokentype/5.0.2" localName="LTPA"/>
</loginMappings>
The com.ibm.wsspi.wssecurity.auth.callback.CallbackHandlerFactory
interface is a factory for javax.security.auth.callback.CallbackHandler.
- The Web services security run time initiates the factory implementation
class and passes the authentication information from Web services security
header to the factory class through the set methods.
- The Web services security run time invokes the newCallbackHandler() method
to obtain the javax.security.auth.CallbackHandler object,
which generates the required security token.
- When the security handler receives an LTPA BinarySecurityToken,
it uses the WSLogin JAAS login configuration
and the newCallbackHandler() method to validate
the security token. If none of the expected token types are found in the SOAP
message Web services security header, the request is rejected with an SOAP
fault. Otherwise, the token type is used to map to a JAAS login configuration
for token validation. If authentication is successful, a JAAS Subject is created
and associated with the running thread. Otherwise, the request is rejected
with a SOAP fault.
The following table shows the authentication methods
and the JAAS login configurations.
Authentication method |
JAAS login configuration |
BasicAuth |
WSLogin |
Signature |
system.wssecurity.Signature |
LTPA |
WSLogin |
IDAssertion |
system.wssecurity.IDAssertion |
Figure 2 shows the receiver security handler in the request
receiver message process.

Request receiver SOAP message process
The default <LoginMapping> is
defined in the server-level ws-security.xml files.
If nothing is defined in the binding file information, the ws-security.xml default
is used. However, an administrator can override the default by defining a
new <LoginMapping> element in the binding file.
- The client reads the default binding information in the ${install_dir}/properties/ws-security.xml file.
- The server run-time component loads the server-level ws-security.xml files, if they exist. The two files are merged in the run time to form one
effective set of default binding information.
On a base application server,
the server run time component only loads the server-level ws-security.xml file.
The server-side ws-security.xml file and the application Web services
security binding information are managed by the administrative console and
by the WSADMIN. You can specify the binding information
during application deployment either through the administrative console or
through the WSADMIN file. The Web services security
policy is defined in the deployment descriptor extension (ibm-webservicesclient-ext.xmi)
and the bindings are stored in the IBM binding extension (ibm-webservicesclient-bnd.xmi).
However, the ${install_dir}/properties/ws-security.xml file
defines the default binding value for the client. If the binding information
is not specified in the binding file, the run time reads the binding information
from the default ${install_dir}/properties/ws-security.xml file.

Lightweight Third Party Authentication
Request sender
Request receiver
Default binding

Securing Web services using XML digital signature
Securing Web services using basicauth authentication
Securing Web services using identity assertion authentication
Securing Web services using signature authentication
Securing Web services using a pluggable token

Login mappings collection
Login mapping configuration settings
Searchable topic ID:
cwbs_loginmappings
Last updated: Jun 21, 2007 8:07:48 PM CDT
WebSphere Business Integration Server Foundation, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.wasee.doc/info/ee/ae/cwbs_loginmappings.html