[Fix Pack 7 or later]

Web services client token cache for SAML

When a SAML token is initially requested, the Web services runtime environment automatically saves the SAMLToken in the current javax.xml.ws.BindingProvider instance. As a result of this automatic client token caching function, subsequent Web services requests can use the SAMLToken from the previous request.

The Web services client token cache for SAML enables Web services clients to reuse SAML tokens when accessing business services. Reusing valid SAML tokens reduces traffic to the Security Token Service (STS) and also reduces the performance impact of sending WS-Trust request messages. There are several requirements for a token to be considered valid and therefore available for caching and reuse.

In order for a SAML token to be reused, the expiration time of the token must be equivalent to, or greater than, the current time. A cache cushion is added to the current time when comparing the token expiration time with the current time so that the token does not expire immediately after it is sent

In addition, a token is valid only if it is sent again to the same business service. The SAML function in WebSphere® Application Server does not verify the AudienceRestriction condition for the SAML token. Therefore, a practical way to ensure that the SAML token is reused for the right audience is to reuse the token only for the same Web service that originally used the token. If an assertion contains the OneTimeUse assertion, the SAML token is not cached.

The SAML function automatically saves the SAMLToken in the current javax.xml.ws.BindingProvider instance after the initial successful token invocation. Subsequent Web services requests can use the SAMLToken from the previous request. To use the cache function, the application design must meet the following requirements:
The following code sample shows how to use the SAMLToken client cache for subsequent token requests:
Service svc = Service.create(QUALIFIED_SERVICE_NAME);
	svc.addPort(QUALIFIED_PORT_NAME, null, null);
	Dispatch<String> dispatch = svc.createDispatch(QUALIFIED_PORT_NAME, String.class, null);
	Map<String, Object> requestContext = dispatch.getRequestContext();
	requestContext.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, ENDPOINT_URL);

	String result = dispatch.invoke(“test  #1”);
//First request

	result = dispatch.invoke(‘test #2”);
//Second request, will use SAMLToken that is cached from  the 1st request

  result = dispatch.invoke(“test #3”);
//Third request  will use SAMLToken that is cached from the 1st request
When you do not want to reuse the same SAMLToken for subsequent requests, you can disable the client side SAMLToken cache with the cacheToken custom property. To disable the client side SAMLToken cache, modify the custom property in the CallbackHandler for the SAMLToken generator. Add the cacheToken property and set the value to false.
Custom property name Value
cacheToken false



Related tasks
Developing SAML applications
Concept topic    

Terms of Use | Feedback

Last updated: Oct 21, 2010 3:36:59 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=compass&product=was-express-iseries&topic=cwbs_tokencacheclientsaml
File name: cwbs_tokencacheclientsaml.html