Manage module chains

A module chain defines a WS-Trust endpoint. It contains a reference to a template and the properties for all modules within that template.

We can define the following fields for a module chain:

Overview tab

Name	Name of the module chain. This field is required.
Description	Description of the module chain. This field is required.
Template	The template that is referenced by this module chain.

Lookup tab:

Request Type

The type of request to associate with this chain. The request is one of the types supported by the WS-Trust specification.

Issue	Issue a new token, based on information that is obtained from the request.
Renew	Renew an expired token.
Validate	Validate the specified security token and return the requested result.
Cancel	Cancels a previously issued token so that it is no longer used.
Key Exchange	Transfer of a new key for use by the receiver of the request.
Other	A custom request type.

URI

A Uniform Resource Indicator for each request type. This field is read-only except when we select Other as the request type. For the Other type, enter the URI for the custom request type.

Lookup Type

XPath

Select this option to enable a text field that can be used to define a custom lookup rule. Use XML Path Language to define the rule.

Traditional WS-Trust Elements

The trust service uses the values in the request for Applies To, Issuer, and Token Type as input to determine which trust service module chain to call. Select this option to show the data entry fields for Applies To, Issuer, and Token Type. We must provide a value for at least one of the following fields for the Traditional WS-Trust Elements:

• Issuer address
• Applies To address
• Token Type selected, where value is not None

Or, if we do not specify one of the above options, then we must select the XPath option, plus a specified XPath.

If we supply values for all of the parameters, including the XPath, then the Issuer, Applies To, and Token Type values take priority over XPath in the runtime.

Applies To

Scope of the token.

Address

The address of the service being requested. For example:

http://sp.example.com:9080/TrustServer/SecurityTokenService

We can use the asterisk (*) wildcard character at the end of a string. For example, token* matches all strings that start with token. We can also use regular expressions in the format of REGEXP:(regular_expression_here). For example, REGEXP:(.*/application.*) matches any string that contains /application. When we specify the scope for single sign-on protocols, this URI is sufficient information for identifying the issuer.

Service Name

A qualified name (QName) that includes a namespace URI and a local part for the Web service. A QName is a term that is defined in XML specifications. A QName consists of a namespace URI plus a local part. For example:

http://sp.example.com:SecurityTokenService

The Service Name field provides a colon (:) to separate the namespace URI from the local part. This field is typically not used for single sign-on protocols, but can be used for Web services security management.

Port Type

Web services operations are grouped by port type. Use this field when there are more than one Web services port types to specify. For example, a stock market data service might provide both a stock quoting service and a stock price history service. Use this field to specify the needed Web service.

http://sp.example.com:RequestSecurityTokenPort

The port type is also a QName. The Port Type field provides a colon (:) to separate the namespace URI from the local part. This field is typically not used for single sign-on protocols, but can be used for Web services security management.

Issuer

Address

The URL for the company or enterprise that issued the token. For example:

example.com

We can use the asterisk (*) wildcard character at the end of a string. For example, token* matches all strings that start with token. We can also use regular expressions in the format of REGEXP:(regular_expression_here). For example, REGEXP:(.*/application.*) matches any string that contains /application. When we specify the scope for single sign-on protocols, this provider ID is sufficient information for identifying the issuer.

Service Name

A qualified name (QName) that includes a namespace URI and a local part for the Web service. A QName is a term that is defined in XML specifications. A QName consists of a namespace URI plus a local part. For example:

http://idp.example.com:myWebService

The Service Name field provides a colon (:) to separate the namespace URI from the local part. This field is typically not used for single sign-on protocols, but can be used for Web services security management.

Port Type

Web services operations are grouped by port type. Use this field when there is more than one Web service port type to specify. For example, a stock market data service might provide both a stock quoting service and a stock price history service. Use this field to specify the needed Web service.

http://idp.example.com:getQuotePortType

The port type is also a QName. The Port Type field provides a colon (:) to separate the namespace URI from the local part. This field is typically not used for single sign-on protocols, but can be used for Web services security management.

Token Type

Define the STS module type. Select a type to map a request message to an STS chain. Select a type other than None for it to be part of the runtime flow.

URI

A Uniform Resource Indicator for each token type. This field is read-only except when we select Other as the token type. For the Other type, enter the URI for the custom token type.

Security tab

Validate Requests

Select to require a signature on the SOAP Body element containing the RequestSecurityToken messages. When we select this option, your Trust Service client must use their private key to sign the body of the SOAP messages in accordance with the Web Services Security SOAP Message Security 1.1 specification.

Select the public key that was provided by the client to validate the signature on the message.

Certificate Database

Database where the certificate is stored.

Certificate Label

Specify the name of the certificate to use for validation.

Send Validation Confirmation

Send signature validation confirmation. When we select this option, the Trust Server includes a SignatureValidationConfirmation element in the Security header in accordance with the Web Services Security SOAP Message Security 1.1 specification.

Sign Responses

Select to sign the Trust Server SOAP response messages. When we select this option, the Trust server uses the private key we select to sign the body of the SOAP response messages in accordance with the Web Services Security SOAP Message Security 1.1 specification.

Provide the corresponding public key to your client so they can validate the signature on the message.

Certificate Database

Database where the certificate is stored.

Certificate Label

Specify the name of the certificate to use for validation.

Include

Determine which elements to include in the digital signature for a Trust Server SOAP response message.

Public Key	Whether to include the public key with your signature.
Subject Key Identifier	Whether to include the X.509 subject key identifier with your signature.
Subject Name	Whether to include the subject name with your signature.
Certificate Data	Whether to include the BASE64 encoded certificate data with your signature.
Issuer Details	Whether to include the issuer name and the certificate serial number with your signature.

The Properties tab contains the properties for all modules within the template. Properties for each module can be viewed and updated by selecting the module on the Template Contents list.

Steps

1. Log in to the local management interface.

2. Click...
   Federation > Manage > Security Token Service

   By default, the Security Token Service Module Chains tab is open. All existing module chains are listed.

3. We can create, modify, or delete module chains.

   Create a module chain

   1. Click Add.
   2. Provide details for the module chain on all tabs.
   3. Click Save.

   4. Deploy the changes.

   Modify a module chain

   1. Select the module chain to modify.
   2. Click Edit.

   3. Edit the details on various tabs as needed.
   4. Click Save.

   5. Deploy the changes.

   Delete a module chain

   1. Select the module chain to delete.
   2. Click Delete.
   3. Click Delete to confirm the deletion.

   4. Deploy the changes.

Parent topic: Manage trust chains