WebSphere Application Server Network Deployment, Version 6.0.x   Operating Systems: AIX, HP-UX, Linux, Solaris, Windows
             [TIP: Focusing the table of contents and search results]

Example: Using the default single sign-on token

Do not use the default single sign-on token in service provider code. This default token is used by the WebSphere Application Server run-time code only.

Size limitations exist for this token when it is added as an HTTP cookie. If you need to create an HTTP cookie using this token framework, you can implement a custom single sign-on token. To implement a custom single sign-on token see Implementing a custom single sign-on token for more information.

Changing the token factory that is associated with the default single sign-on token

When the default single sign-on token is generated, the application server utilizes the TokenFactory class that is specified using the com.ibm.wsspi.security.token.singleSignonTokenFactory property. To modify this property using the administrative console, complete the following steps:
  1. Click Security > Global security.
  2. Under Additional properties, click Custom properties.
The com.ibm.ws.security.ltpa.LTPAToken2Factory token factory is the default that is specified for this property. This token factory creates a single sign-on (SSO) token called LtpaToken2, which WebSphere Application Server uses for propagation. This token factory uses the AES/CBC/PKCS5Padding cipher. If you change this token factory, you lose the interoperability with any servers running a version of WebSphere Application Server prior to version 5.1.1 that use the default token factory. Only servers running WebSphere Application Server Version 5.1.1 or later with propagation enabled are aware of the LtpaToken2 cookie. If all of your application servers use WebSphere Application Server Version 5.1.1 or later and all of your servers use your new token factory this awareness is not a problem.
If you need to perform your own signing and encryption of the default single sign-on token, you must implement the following classes:
  • com.ibm.wsspi.security.ltpa.Token
  • com.ibm.wsspi.security.ltpa.TokenFactory
Your token factory implementation instantiates (createToken) and validates (validateTokenBytes) your token implementation. You can use the Lightweight Third-Party Authentication (LTPA) keys passed into the initialize method of the token factory or you can use your own keys. If you use your own keys, they must be the same everywhere to validate the tokens that are generated using those keys. See the API documentation, available through a link on the front page of the information center, for more information on implementing your own custom token factory. To associate your token factory with the default single sign-on token using the administrative console, complete the following steps:
  1. Click Security > Global security.
  2. Under Additional properties, click Custom properties.
  3. Locate the com.ibm.wsspi.security.token.singleSignonTokenFactory property and verify that the value of this property matches your custom TokenFactory implementation.
  4. Verify that your implementation classes are put into the app_server_root/classes directory so that the WebSphere Application Server class loader can load the classes.
  5. Verify that your implementation classes are located in the ${USER_INSTALL_ROOT}/classes directory so that the WebSphere Application Server class loader can load the classes.



Related concepts
Security attribute propagation
Related tasks
Propagating security attributes among application servers
Implementing a custom single sign-on token
Reference topic    

Terms of Use | Feedback

Last updated: Mar 8, 2007 8:14:28 PM CST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/rsec_defssotoken.html

© Copyright IBM Corporation 2005, 2006. All Rights Reserved.
This information center is powered by Eclipse technology. (http://www.eclipse.org)