WAS v8.5 > Develop applications > Develop web services - Security (WS-Security) > Develop applications that use Web Services Security > Develop message-level security for JAX-WS web services > Secure web services applications using the WSS APIs at the message level > Secure messages at the request generator using WSS APIs > Secure messages at the request generator using WSS APIs

Attaching the generator token using WSS APIs to protect message authenticity

When we specify the token generator, the information is used on the generator side to generate the security token.

The token processing and pluggable token architecture in the Web Services Security run time reuses the same security token interface and JAAS Login Module from the Web Services Security APIs (WSS API). The same implementation of token creation and validation can be used in both the WSS API and the WSS SPI in the Web Services Security run time.

Restriction: The com.ibm.wsspi.wssecurity.token.TokenGeneratorComponent interface is not used with JAX-WS web services. If we are using JAX-RPC web services, this interface is still valid.

Note the key name (KeyName) element is not supported in the application server because there is no KeyName policy assertion defined in the current OASIS Web Services Security draft specification.

The JAAS callback handler (CallbackHandler) and the JAAS login module (LoginModule) are responsible for creating the security token on the generator side and validating (authenticating) the security token on the consumer side.

For example, on the generator side, the Username token is created by the JAAS LoginModule and using the JAAS CallbackHandler to pass the authentication data. The JAAS LoginModule creates the Username SecurityToken object and passes it to the Web Services Security run time.

Then, on the consumer side, the Username Token XML format is passed to the JAAS LoginModule for validation or authentication and the JAAS CallbackHandler is used to pass authentication data from the Web Services Security run time to the LoginModule. After the token is authenticated, a Username SecurityToken object is created and passed it to the Web Services Security run time.

WebSphere Application Server does not support a stackable login module with the WAS default login module implementation, meaning adding the login module before or after the WAS login module implementation. To stack the login module implementations, you must develop the required login modules because there is no default implementation.

The com.ibm.websphere.wssecurity.wssapi.token package provided by WAS includes support for these classes:

In addition, WAS provides the following pre-configured sub-interfaces for security tokens:

The Username token, the X.509 tokens, and the LTPA tokens are used by default for message authenticity. The derived key token and the X.509 tokens are used by default for signing and encryption.

The WSS API and WSS SPI are only supported on the client. To specify the security token type on the generator side, we can also configure policy sets using the dmgr console. We can also use the WSS APIs or policy sets for matching consumer security tokens.

The default Login Module and Callback implementations are designed to be used as a pair, meaning both a generator and a consumer part. To use the default implementations, select the appropriate generator and consumer security token in a pair. For example, select system.wss.generate.x509 in the token generator and system.wss.consume.x509 in the token consumer when the X.509 token is required.

To configure the generator-side security token, use the appropriate pre-configured token generator interface from the WSS APIs to complete the following token configuration process steps:

  1. Generate the wssFactory instance.
  2. Generate the wssGenerationContext instance.

    The WSSGenerationContext interface stores the components for generating WS-Security, such as the signing and encryption information, the security token, and the time stamp. When the generate() method is called, all of these components are generated.

  3. Create the generator-side components, such as the WSSSignature and the WSSEncryption objects.

  4. Specify a JAAS configuration by specifying the name of the JAAS login configuration. The JAAS configuration specifies the name of the JAAS configuration. The JAAS configuration specifies how the token logs in on the consumer side. Do not remove the predefined system or application login configurations. However, within these configurations, we can add module class names and specify the order in which WAS loads each module.
  5. Specifiy a token generator class name. The token generator class name specifies the required information to generate the SecurityToken. The Username token, the X.509 tokens, and the LTPA tokens are used by default for message authenticity.
  6. Specifiy the settings for the callback handler by specifying a callback handler class name and also specifies the callback handler keys. This class name is the name of the callback handler implementation class used for the plug-in to the security token framework.

    The callback handler implementation obtains the required security token and passes it to the token generator. The token generator inserts the security token in the Web Services Security header within the SOAP message. Also, the token generator is a plug-in point for the pluggable security token framework. Service providers can provide their own implementation, but the implementation must use the WSSGenerationContext interface.

    WAS provides the following default callback handler implementations for the generator side:

    com.ibm.websphere.wssecurity.callbackhandler.PropertyCallback

    This class is a callback for handling the name-value pair in elements in the WS-Security configuration XMI files.

    com.ibm.websphere.wssecurity.callbackhandler.UNTGUIPromptCallbackHandler

    This class is a callback handler for the Username token with the GUI prompt on the generator side. This instance is used to set the WSSGenerationContext object to generate a Username token.

    com.ibm.websphere.wssecurity.callbackhandler.UNTGenerateCallbackHandler

    This class is a callback handler for the Username token on the generator side. This instance is used to set into WSSGenerationContext object to attach a Username token. Use this implementation for a Java EE application client only.

    com.ibm.websphere.wssecurity.callbackhandler.X509GenerateCallbackHandler

    This class is a callback handler used to generate the X.509 certificate that is inserted in the Web Services Security header within the SOAP message as a binary security token on the generator side. This instance is used to generate the WSSSignature and WSSEncryption objects, set the objects into the WSSGenerationContext object to generate the X.509 binary security tokens. A keystore and a key definition are required for this callback handler. If we use this implementation, a key store password, path, and type must be provided on the generator side.

    com.ibm.websphere.wssecurity.callbackhandler.LTPAGenerateCallbackHandler

    This class is a callback handler for the Lightweight Third Party Authentication (LTPA) tokens on the generator side. This instance is used to generate WSSSignature object and WSSEncryption object to generate a LTPA token.

    This callback handler is used to validate the LTPA security token inserted in the Web Services Security header within the SOAP message as a binary security token. However, if the user name and password are specified, WAS authenticates the user name and password to obtain the LTPA security token rather than obtaining it from the Run As Subject. Use this callback handler only when the web service is acting as a client on the application server. It is recommended that we do not use this callback handler on a Java EE application client. If we use this implementation, a basic authentication user ID and password must have been provided on the generator side.

    com.ibm.websphere.wssecurity.callbackhandler.KRBTokenConsumeCallbackHandler

    This class is a callback handler for the Kerberos v5 token on the generator side. This instance is used to set the WSSGenerationContext object to generate the Kerberos v5 AP-REQ as a binary security token. The instance is also used to generate the WSSSignature and WSSEncryption objects to use the Kerberos session key or derived key in the SOAP message signature and encryption.

  7. If a X.509 token is specified, additional token information is also specified.

    Information for X.509 token. Use the X.509 token for signing and encryption.

    Token Information Description
    storeRef The reference name of the keystore.
    storePath The keystore file path from which the keystore is loaded, if needed. It is recommended that we use the ${USER_INSTALL_ROOT} in the path name as this variable expands to the WAS path on your machine. This path is required when we use the X.509 tokens callback handler implementations.
    storePassword The password used to check the integrity of the keystore, or the keystore password used to unlock the keystore and to access the keystore file. The keystore and its configuration are used for some of the default callback handler implementations provided by WAS.
    storeType The keystore type of keystore used for the key locator. This selection indicates the format used by the keystore file. The following values are available for selection:

    JKS

    Use this option if the keystore uses the Java Keystore (JKS) format.

    JCEKS

    Use this option if the Java Cryptography Extension is configured in the SDK. The default IBM JCE is configured in WAS. This option provides stronger protection for stored private keys using Triple DES encryption.

    JCERACFKS

    Use JCERACFKS if the certificates are stored in a SAF key ring (z/OS only).

    PKCS11KS (PKCS11)

    Use this format if the keystore uses the PKCS#11 file format. Keystores using this format might contain RSA keys on cryptographic hardware or might encrypt keys that use cryptographic hardware to ensure protection.

    PKCS12KS (PKCS12)

    Use this option if the keystore uses the PKCS#12 file format.
    alias The key alias name. The key alias is used by the key locator to find the key within the keystore file.
    keyPassword The key password used for recovering the key. This password is needed to access the key object within the keystore file.
    keyName The name of the key. For digital signatures, the key name is used by the request generator or response consumer signing information to determine which key is used to digitally sign the message. For encryption, the key name is used to determine the key used for encryption. The key name must be a fully qualified, distinguished name (DN). For example, CN=Bob,O=IBM,C=US.
    certStores A list of certificate stores. A collection certificate store includes a list of untrusted, intermediary certificates and certificate revocation lists (CRLs). This step configures a collection certificate store and certificate revocation lists for the generator bindings.
    identityAssertion Whether identity assertion is used. Selects this item if identity assertion is defined. This option indicates that only the identity of the initial sender is required and inserted into the Web Services Security header within the SOAP message. For an X.509 token generator, the application server sends the original signer certification only.
    requestorCertificate Whether the certificate of the requestor is used.

    The following can be specified for a X.509 token:

    1. Without any keystore.
    2. With a trust anchor. A trust anchor specifies a list of keystore configurations containing trusted root certificates. These configurations are used to validate the certificate path of incoming X.509-formatted security tokens. For example, when we select the trust anchor or the certificate store of a trusted certificate, configure the trust anchor and the certificate store before setting the certificate path.
    3. With a keystore used for the key locator.

      First, you must have created the keystore file, using a key tool utility, for example. The keystore is used to retrieve the X.509 certificate. This entry specifies the password used to access the keystore file. Keystore objects within trust anchors contain trusted root certificates used by the CertPath API to validate the trustworthiness of a certificate chain.

    4. With keystore used for the key locator and the trust anchor.
    5. With a map that includes key-value pairs. For example, you might specify the value type name and the value type Uniform Resource Identifier (URI). The value type specifies the namespace URI of the value type for the generated token, and represents the token type of this class:

      ValueType: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3

      Specifies an X.509 certificate token.

      ValueType: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509PKIPathv1

      Specifies X.509 certificates in a public key infrastructure (PKI) path. This callback handler is used to create X.509 certificates encoded with the PkiPath format. The certificate is inserted in the Web Services Security header within the SOAP message as a binary security token. A keystore is required for this callback handler. A CRL is not supported by the callback handler; therefore, the collection certificate store is not required or used. If we use this implementation, you must provide a key store password, path, and type on this panel.

      ValueType: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#PKCS7

      List of X.509 certificates and certificate revocation lists in a PKCS#7 format. This callback handler is used to create X.509 certificates encoded with the PKCS#7 format. The certificate is inserted in the Web Services Security header in the SOAP message as a binary security token. A keystore is required for this callback handler. We can specify a certificate revocation list (CRL) in the collection certificate store. The CRL is encoded with the X.509 certificate in the PKCS#7 format. If we use this implementation, you must provide a key store password, path, and type.

      For some tokens, WAS provides a predefined local name for the value type. When we specify the following local name, we do not need to specify a value type URI:

      ValueType: http://www.ibm.com/websphere/appserver/tokentype/5.0.2

      For an LTPA token, we can use LTPA for the value type local name. This local name causes http://www.ibm.com/websphere/appserver/tokentype/5.0.2 to be specified for the value type Uniform Resource Identifier (URI).

      ValueType: http://www.ibm.com/websphere/appserver/tokentype/5.0.2

      For LTPA token propagation, we can use LTPA_PROPAGATION for the value type local name. This local name causes http://www.ibm.com/websphere/appserver/tokentype to be specified for the value type Uniform Resource Identifier (URI).

  8. If the Username token is specified as the token generator class name, the following token information can be specified:

    1. Whether to use IdentityAssertion option. This option is selected if identity assertion is defined. This option indicates that only the identity of the initial sender is required and inserted into the Web Services Security header within the SOAP message. For example, WAS sends only the user name of the original caller for a Username token generator.
    2. Whether to use RunAsSubject identity option. This option is used if an identity assertion is defined and to use the Run As identity instead of the initial caller identity for identity assertion in a downstream call. This option is valid only if we have configured the Username token as the token generator.
    3. Whether to use sendRealm.
    4. Whether to specify the nonce.

      This option indicates whether a Nonce is included for the token generator. Nonce is a unique, cryptographic number that is embedded in a message to help stop repeat, unauthorized attacks of Username tokens. Nonce is valid only when the generated token type is a Username token, and it is available only for the request generator binding.

    5. Keyword of the time stamp. This option indicates whether to verify a time stamp in the Username token. The time stamp is valid only when the incorporated token type is a Username token.
    6. Specifies a map that includes key-value pairs. For example, you might specify the value type name and the value type Uniform Resource Identifier (URI). The value type specifies the namespace URI of the value type for the generated token, and represents the token type of this class:

      URI value type: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken

      Specifies a Username token.

  9. If the Kerberos v5 token is specified as the token generator class name, the following token information can be specified:
    Token Information Description Default Value
    name Kerberos client principal name  
    password Kerberos client password  
    realm Kerberos realm associated with the Kerberos client Default realm name in Kerberos configuration file.

    Specify null to use the default value.

    targetService Kerberos service name associated with the target web services.  
    targetHost Kerberos realm name associated with the Kerberos service name.  
    tokenValueType Kerberos token value type in QName defined by Oasis Kerberos Token Profile v1.1 specification. http://docs.oasis-open.org/wss/oasis-wss-kerberos-token-profile-1.1#GSS_Kerberosv5_AP_REQ
    targetRealm Kerberos realm name associated with the Kerberos service name. Default realm name in the Kerberos configuration file
    prompt A boolean value to enable the login prompt. false
    supportTokenRequireSHA1 A boolean value to require a SHA1 key used in subsequent request messages when the Kerberos token is used as a supporting token. false

    SHA1 key is consumed only if the supporting Kerberos token is protected. If set to true, the SHA1 key is always consumed.

    alwaysAPREQ A boolean value to indicate the client should always send the Kerberos AP_REQ token in the request messages. false

    The SHA1 key is used instead in the subsequent messages. If set to true, the Kerberos AP_REQ token is always used.

    requireDKT A boolean value to require a derived key for message protection. false
    clabel The client label for the derived key. WS-SecureConversation

    Specify null to use the default value.

    slabel The service label for the derived key. WS-SecureConversation

    Specify null to use the default value.

    keylen The length of the derived key. 16

    Specify zero to use the default value

    noncelen The length of the nonce. 16

    Specify zero to use the default value

    encComponent An instance of WSSEncryption. Set encComponent and sigComponent to null to initialize this first for either the encryption or signature component. Then, use the initialized component only in the callback handler constructor for the second component.
    sigComponent An instance of WSSSignature. Set encComponent and sigComponent to null to initialize this first for either the encryption or signature component. Then, use the initialized component only in the callback handler constructor for the second component.

    Additional token value types are defined in the OASIS Kerberos Token Profile v1.1 specification. Specify the token value type as the local name. It is not necessary to specify the value type URI for the Kerberos v5 token.

    • http://docs.oasis-open.org/wss/oasis-wss-kerberos-token-profile-1.1#Kerberosv5_AP_REQ
    • http://docs.oasis-open.org/wss/oasis-wss-kerberos-token-profile-1.1#Kerberosv5_AP_REQ1510
    • http://docs.oasis-open.org/wss/oasis-wss-kerberos-token-profile-1.1#GSS_Kerberosv5_AP_REQ1510
    • http://docs.oasis-open.org/wss/oasis-wss-kerberos-token-profile-1.1#Kerberosv5_AP_REQ4120
    • http://docs.oasis-open.org/wss/oasis-wss-kerberos-token-profile-1.1#GSS_Kerberosv5_AP_REQ4120

  10. If Secure Conversation is used for message protection, the following information must be specified:
    Information Description
    bootstrapWSSGenerationContext The bootstrap configuration used to secure the RequestSecurityToken (RST) token.
    bootstrapWSSConmingContext The bootstrap configuration used for consuming a secured RequestSecurityTokenResponse (RSTR).
    ENDPOINT_URL The service end point URL.
    EncryptionAlgorithm This determines the key size.
    cLabel The client label used when creating the derived key.
    sLabel The server label used when creating the derived key.

  11. Set the components into the wssGenerationContext object.
  12. Invoke the wssGenerationContext.process() method.


Results

Use the Web Services Security API (WSS API) process, we can configured the token generator.

Next, specify a similar token consumer configuration.


Subtopics


Related concepts:

Derived key token
Security context token
Binary security token
Security token
Username token
XML token


Related


Validating the consumer token to protect message authenticity


+

Search Tips   |   Advanced Search