We've integrated the gateway with CTS (CoreBlox Token Service) using SiteMinder behind that. The response message from CTS enumerates properties about the user and the resulting token. The gateway can use this information for authorization decisions. This integration places the token into the set-cookie header on the response to the client and then uses the cookie on subsequent requests to look up the cached CTS response. The cached CTS response will expire at the token's idle timeout. If the maximum timeout is reached without the idle timeout being exceeded then the cached user credentials used to initially request the token will be used to request a new token (and update the client cookie). By using CTS to surface this information to the gateway it is not required to validate the token at the SiteMinder server for every request, eliminating the latency associated with this call. Additionally the gateway can act as the authorization point for requests based on the user information surfaced via CTS, where this function is usually performed by the SiteMinder server at the request of the back-end. This integration removes this workload and latency from the back-end application server.
The cost of this solution is that the token information is cached on the gateway increasing its workload. Because the token is cache and validated on the gateway the SiteMinder server does not see the token being used and therefore thinks it expires at the start time + idle timeout, while the gateway is most likely still using it (and the gateway is unaware that the SiteMinder server has expired the token). This also means that if the user's properties or the SiteMinder token timeout settings change then the gateway can hold onto existing tokens until they reach the maximum expiration an get renewed.
Some of these risks can be mitigated by reducing the timeout of the tokens; however, the shorter that is the more often the gateway will have to communicate to CTS thereby reducing the time savings.
