Security tokens

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

See the Lightweight Third Party Authentication (LTPA) article in the WebSphere Application Server Information Center for more information.

Simple token support

By default, WebSphere sMash uses an encrypted token for storing user credentials.

# SimpleToken support
/config/security/token/simple += {
	"tokenExpiration": 120,
	"ssoDomains" : ["projectzero.org"]
}

As illustrated in the previous sample, token settings may contain the following values:

tokenExpiration (optional)

The expiration limit of the SimpleToken in minutes. The default value is 120 minutes and is validated at the time the token is validated to determine if 120 minutes have passed since the last time the token was validated.

ssoDomains (optional)

List of possible values for the simple 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.

LTPAToken2 support

Advanced Topic

Use of Lightweight Third Party Authentication (LTPA) 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 various IBM products such as between WebSphere Application Server Version 6.1 and WebSphere sMash, 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 absolute or relative path of the LTPA key import file. A relative filename will search the virtual directory structure to locate the file under the config directory. 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 then you can override the default value for whether the cookie should be be secure. For example, a proxy was rewrites the request from secured to unsecured after going through the firewall. The following code example illustrates how to override the default value and creates a secured cookie that would only be sent for SSL based requests:

/config/security/token/securedCookie=true

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.

There are many types of authentication that do not require a security token. Two examples of authentication types that do not require security tokens are Basic and Digest Authentication. A token is not required for either of these authentication types because of how each of these authenticate types manage user credentials. When a user requests a protected resource, the client is challenged with a WWW-Authenticate header requesting the user provide their username and password. Once the user enters in their credentials, the credentials are included in the request header authorization on each request. Since these credentials are included, the server can use these credentials to validate the user instead of requiring a security token to validate the user. The following example shows the configuration to disable token support:

/config/security/token/tokenType=""