Web Services Security service provider programming interfaces

Several Service Provider Interfaces (SPIs) are provided to extend the capability of the Web Services Security runtime.

The following list contains the SPIs available for WAS:

Tasks

• com.ibm.wsspi.wssecurity.config.KeyLocator is an abstract for obtaining the keys for digital signature and encryption. The following list contains the default implementations:
  1. com.ibm.wsspi.wssecurity.config.KeyStoreKeyLocator implements the Java key store.
  2. com.ibm.wsspi.wssecurity.config.WSIdKeyStoreMapKeyLocator povides a mapping of the authenticated identity to a key for encryption or, the implementation uses the default key specified.
  3. com.ibm.wsspi.wssecurity.config.CertInRequestKeyLocator Provides the capability of using the signer key for encryption in the response message. This implementation is typically used in the response sender configuration.

• com.ibm.wsspi.wssecurity.id.TrustedIDEvaluator is an interface used to evaluate the trust for identity assertion. The default implementation is com.ibm.wsspi.wssecurity.id.TrustedIDEvaluatorImpl, which enables us to define a list of trusted identities.

• The JAAS CallbackHandler application programming interfaces (APIs) are used for token generation by the request sender. This interface can be extended to generate a custom token that can be inserted in the Web Services Security header. The following list contains the default implementations provided by WAS:
  1. com.ibm.wsspi.wssecurity.auth.callback.GUIPromptCallbackHandler presents a login prompt to gather the basic authentication data. Use this implementation in the client environment only.
  2. com.ibm.wsspi.wssecurity.auth.callback.StdinPromptCallbackHandler collects the basic authentication data in the standard in (stdin) prompt. Use this implementation in the client environment only.

     Restriction: If we have a multi-threaded client and multiple threads attempt to read from standard in at the same time, all the threads will not successfully obtain the user name and password information. Therefore, we cannot use the com.ibm.wsspi.wssecurity.auth.callback.StdinPromptCallbackHandler implementation with a multi-threaded client where multiple threads might attempt to obtain data from standard in concurrently.

  3. com.ibm.wsspi.wssecurity.auth.callback.NonPromptCallbackHandler reads the basic authentication data from the application binding file. This implementation might be used on the server side to generate a user name token.
  4. com.ibm.wsspi.wssecurity.auth.callback.LTPATokenCallbackHandler Generates a LTPA token in the Web Services Security header as a binary security token. If basic authentication data is defined in the application binding file, it is used to perform a login, to extract the LTPA token from the WebSphere credentials, and to insert the token in the Web Services Security header. Otherwise, it will extract the LTPA security token from the invocation credentials (RunAs identity) and insert the token in the Web Services Security header.

What to do next

The JAAS LoginModule API is used for token validation on the request receiver side of the message. We can implement a custom LoginModule API to perform validation of the custom token on the request receiver of the message. After the token is verified and validated, the token is set as the caller and then run as the identity in the WAS runtime. The identity is used for authorization checks by the containers before a Java EE resource is invoked. The following list presents the default AuthMethod configurations provided by WAS:

BasicAuth

Validates a user name token.

Signature

Maps the distinguished name (DN) of a verified certificate to a JAAS subject.

IDAssertion

Maps a trusted identity to a JAAS subject.

LTPA

Validates an LTPA token that is received in the message and creates a JAAS subject.

Related:

LTPA

Web Services Security model in WAS

Login mappings

Web Services Security support