Security tokens

IBM® WebSphere® sMash authentication provides the pluggable token support for various types of security tokens.

By default, WebSphere sMash provides simple session based authentication. In addition to session based tracking of user login, WebSphere sMash provides LTPAToken2 support that is compatible with what is included in WebSphere Application Server 6.1. The following sections of this article provide information about the tokens supported and how that support is provided:

For additional details regarding LTPA tokens, see the LTPA (Lightweight Third Party Authentication) article in the IBM Information Center.

Simple token support

By default, WebSphere sMash uses a token based on a session and cookie combination for storing user credentials with the limitation of the token being scoped to a single application.

LTPAToken2 support

Advanced Topic Use of LTPA (Lightweight Third Party Authentication) tokens is considered an advanced topic and should not be required for most applications. Another type of token support is LTPAToken2 support. To enable single sign on token sharing across applications or across servers, LTPAToken2 is required. The following configuration example demonstrates how to configure LTPAToken2 support:

# LTPAToken2 support
@include "security/token/ltpa2.config"{
	"keyImportFile": "ltpakeys.txt",
	"keyPassword" : "<xor>keypass",
        "ssoDomains" : ["projectzero.org"]

}

The settings should contain the following information:

keyImportFile (required): The relative path of the LTPA key import file from the configuration folder of the application. The file is exported by WebSphere Application Server. To learn how to export the LTPA keys, see the Exporting Lightweight Third Party Authentication keys article in the IBM Information Center.
keyPassword (required) (xor supported): The password to extract the LTPA keys from the LTPA key import file.
tokenExpiration (optional): The expiration limit of the LTPAToken2 in minutes. The default value is 120 minutes.
ssoDomains (optional): List of possible values for the ltpa token cookie domain. Each element in the list will be matched against the server name obtained the request (GlobalContext.zget(Request.serverName)). If the serverName, obtained from the GlobalContext, ends with a value from the list of ssoDomains, the cookie will be created with that domain (first match wins). The default value for the domain is null.

Default configuration for token support

The cookie that is generated for tokens is scheme specific for SSL based authentication. If the authenticating request is SSL based, the cookie is created with the secure option enabled. If authentication is not SSL based, then the cookie is created with the secure option set to false. This cookie can be used for SSL and non-SSL requests after authentication is performed for a resource that is not SSL protected. The following example shows the default configuration (enabled by default and requiring no additional configuration) used for simple token support:

/config/security/token/tokenType="Simple"
/config/security/token/securedCookie=false

If WebSphere sMash cannot determine that the client request was actually SSL based (for example a proxy was rewriting the request from secured to unsecured after going through the firewall), then you can override the default value for whether the cookie should be be secure. To do this, the following code example would be required in the application zero.config:

/config/security/token/securedCookie=true

This creates a secured cookie that would only be sent for SSL based requests.

Best practices for token support

The recommended configuration for secured applications is to enable SSL for all secured resources, including the login page. This provides the most secured environment for sending information related to authentication (credentials and tokens) between the client and server. See the Requiring SSL section for more information about requiring SSL for accessing resources.