+

Search Tips   |   Advanced Search

SAML token library APIs

The SAML token library application programming interfaces (APIs) provide methods we can use to create, validate, parse, and extract SAML tokens. The library implementation for SAML Version 1.1 and SAML v2.0 provides three types of subject confirmation:

We can use the SAML token library APIs to create, validate, and extract the attributes of a SAML HoK or bearer token. SAML token propagation from web services SOAP messages is also discussed. Sample code is provided to demonstrate the use of the APIs. WebSphere Application Server with SAML provides default policy sets to support the bearer and HoK subject confirmation. The SAMLTokenFactory API is the primary SAML token library programming interface. SAMLTokenFactory supports creating, parsing, and validating both SAML 1.1 and SAML 2.0 tokens. Using the SAMLTokenFactory API, we can create ProviderConfid, RequesterConfig, and ConsumerConfig configuration objects to define the required SAML token characteristics. Starting with WAS Release 8, we can use the Web Services Security (WSS) API class:

When there is no concern of confusion we use the term SAMLToken instead of using its complete package name. Use WSS API to request SAMLToken processing from an external Security Token Service (STS), to propagate SAMLTokens in SOAP request messages, and to use a symmetric or asymmetric key identified by SAMLTokens to protect SOAP messages.

The WSS API SAML support complements the interfaces:

SAMLTokens generated using the method:

...can be processed by the SAMLTokenFactory and WSSTrustClient programming interfaces. Conversely, SAMLTokens generated by SAMLTokenFactory or returned by WSSTrustClient can be used in WSS API. Deciding which API to use in the application depends on your specific needs. WSS API SAML support is self contained in the sense that it provides functionality equivalent to that of the SAMLTokenFactory and WSSTrustClient interfaces as far as web services client applications are concerned. The SAMLTokenFactory interface has additional functions to validate SAMLTokens and to create the JAAS Subject that represents authenticated SAMLTokens. This validation is useful for the Web services provider side. When we develop applications to consume SAMLTokens, the SAMLTokenFactory programming interface is more suitable for you.


Configuration of token creation parameters

When we configure the token creation parameters, the configuration information relates to either the requesting entity, the issuing entity, or the receiving entity. In this example, configuration information is defined for the requesting and the issuing entities. For each type of supported subject confirmation, the SAML token library provides pre-configured attributes for the requesting entity. These attributes are used during the creation of the self-issued SAML token by the WebSphere runtime environment. A self-issued SAML token is one generated locally, instead of one that is requested from a Security Token Service (STS). If we need to customize the attributes for a default parameter, use the RequesterConfig parameter. See the RequesterConfig parameter in the SAMLTokenFactory API topic.

First, set up the requestor configuration information:

Next, set the recipient public key alias and optionally, the authentication method:

Then set the issuer configuration attributes:


SAML token factory instance creation

Use the SAMLTokenFactory class, specifying the SAML token type, either Version 1.1 or v2.0. Set additional parameters for creating the SAML token.

Use the SAMLTokenFactory class with the SAML token type:

Set additional parameters in the CredentialConfig object using the caller subject or the runAsSubject:


SAML token creation

Create the SAML token using the token factory:


SAML token validation

An entity that receives a SAML token, such as a business service, can use the SAML token library API to validate the token before using it. For example, the service needs to validate the token before extracting the SAML attributes from the requester. An existing SAML assertion document can be validated using the configuration data from the consumer.

The following API code validates the token:


SAML token identity mapped to a subject

A SAML token can be used to create a subject. The name identifier in the SAML token is mapped to a user in the user registry to obtain the principal name for the subject.


Parse assertion elements

The recipient of a SAML token can parse and extract assertion elements from the SAML token using the SAMLToken APIs, which are included in the SAML token library API. For example, the token creation time can be extracted using this code:

Extract the name of the token issuer and the confirmation method as follows:

If the extracted subject confirmation method is returned as holder-of-key confirmation, then we can use the following API to retrieve the bytes for the key material:

For more information about all the SAML APIs, read the API documentation for the SAMLToken interface.


SAML token attributes extraction

Extract SAML attributes from the initiating entity (service requester) using the SAMLToken API, as shown in the following code snippets.


Sample code

The sample code demonstrates how to use the SAML token library APIs to accomplish some of the operations previously described. A JVM property that points to the location of the SAML properties file is a prerequisite for running this code. The SAML properties file, SAMLIssuerConfig.properties, must contain configuration attributes related to the issuer (provider) of the SAML token.

The default location of the SAMLIssuerConfig.properties file for the cell level is: app_server_root/profiles/$PROFILE/config/cells/$CELLNAME/sts.

For the server level, the default location is: app_server_root/profiles/$PROFILE/config/cells/$CELLNAME/nodes/$NODENAME/servers/$SERVERNAME.


Sample code output

  • API documentation - Application programming interfaces (package:com.ibm.websphere.wssecurity.wssapi.token)