SAML Token Caching for Improved Identity Performance

Issuing SAML tokens in a SOA or Cloud policy operation is a common use case, but there are two core concerns that need to be addressed in production-class deployments:

• Public Key cryptography required to sign the token is expensive in terms of CPU usage
• If there is a single path through the policy that creates SAML tokens, it's likely that there will be times when:
  • The token issued for the last message to pass through the policy will still be valid
  • A new token issued would also be valid
• Having multiple valid tokens increases the attack surface of cryptographic attacks and is considered bad practice.

Layer 7 offers a comprehensive set of data and token caching capabilities in its products to speed mediation and identity operations.

As an example of SAML token caching, we can create a policy where tokens are issued and cached for periods very similar to their validity period so as to reduce the number of tokens being issued. To do this, we create a token caching assertion with a selectable cache key. It’s important to define a cache key that is unique for a given authorization. Furthermore, it's important that you have the cache key include something about the target service so that the usage patterns for the tokens don't collide. Our cache keys are automatically hashed, so there's no need to hash them as part of policy. Use something like: name of the Identity Provider; successful username; and a representative name of the target service separated by a delimiter. With good policy design, there's no need to include passwords. If the inbound message was secured with (for instance) username and password, it would be important to put the creation of the cache key after those credentials were checked. Layer 7 has an automatic context variable that encodes the identity provider and the validated user in a single value: ${request.clientid}. This makes a good choice for a cache key something like ${request.clientid}/ApplicationName. Below is the resulting policy fragment:

The resulting policy fragment takes advantage of the following best practices:

1. Gather credentials early
2. Validate credentials
3. Create a cache key based on successful credential validation
4. Perform a look up using that cache key
5. If found, retrieve token to a context variable
6. If not found, generate a token to context variable and store the context variable in a cache
7. Finally, add the context variable to the message and sign