WS-Security service provider programming interfaces

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

There is an important distinction between Version 5.x and V6 and later applications. The information in this article supports V5.x applications only that are used with WAS V6.0.x and later. The information does not apply to V 6.0.x and later applications.

The following list contains the SPIs that are available for WAS:

 

• 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 you to define a list of trusted identities.

• The (JAAS) CallbackHandler 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 WS-Security header.

  The following list contains the default implementations that are 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 cllects the basic authentication data in the standard in (stdin) prompt. Use this implementation in the client environment only.

  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 WS-Security header. Otherwise, it will extract the LTPA security token from the invocation credentials (RunAs identity) and insert the token in the WS-Security header.

 

Next steps

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 Java Authentication and Authorization Service (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 concepts

Lightweight Third Party Authentication
WS-Security model in WAS
Login mappings

 

Related tasks

Secure Web services for V5.x applications using XML digital signature

 

Related

WS-Security support