Caching Request Attributes At Gateway

[#1]

Is there any caching framework available at gateway level for above mentioned use case.

Use Case :

• Client obtains a valid access token, which will be passed to every subsequent API call
• API gateway will use the access token to obtain the auth cookies:
  • computes a one-way hash of the access token and uses it to access auth cookies in the API Cache
  • if not in the cache, then it retrieves the auth cookies from Authentication Server
  • if invalid, returns an authentication error
  • if valid, adds them to the cache with an expiration time equal to the expiration time of the Authentication server session and injects them in the request, much like in a call coming from a browser

we do not use verifyaccestoken/generateAccessToken ,instead we use service callout to fetch and validate the open AM token from external auth server.

So we would be heading PopulateCache and LookUpCache approach .

A key value object to be stored would be like

"f2d2596d-f41d-42f1-ba15-a30dcf584dcd" :"cookiesActualValue,TTL"

This single KVM object will have multiple objects [sample object shown above] .with each cache entry to have a Time to live same as lifetime of the open AM auth token[as and when issued]. Is there a way we can provide the TTL for each entry in this cache object and then invalidate that entry from cache object.

[DChiesa]

I don't know what you mean by "caching framework".

Apigee Edge has a cache that can be populated and accessed via the PopulateCache and LookupCache policies. You can specify any key you like when using these cache primitives.

The flow you described will work fine. Some feedback.

• the token itself is a hash. There's no need to hash it again, to create the cache key.
• if I were designing this, I would obtain the credentials from the OpenAM server at the time the original token was issued. Then I would attach the credentials (cookies?) to the token as attributes. Finally, I would set the lifetime of the token to match the lifetime of the cookies. In this case there is no need for PopulateCache and LookupCache at all. The cookies will be retrieved implicitly when you call OAuthV2/VerifyAccessToken .

You can read about Custom Attributes here:
http://docs.apigee.com/api-services/content/customizing-access-tokens

[#3]

HI @Dino Thanks for suggestion.

May i know how would you save cookies against a authtoken as attributes in gateway. Consider the fact that openAM server is out of my jurisdiction .I cannot cache anything in OpenAm . Can i do this without using populateCache and LookupCache or i have to use these policies?

regards

arpit

[DChiesa]

In Apigee Edge, you may attach cookies or other data as custom attributes on oauth tokens. You can do this at the time the token is issued - in other words at the time in the proxy flow that the OAuthV2/GenerateAccessToken policy is executed. An OAuthV2/GAT policy configuration that stores 2 custom attributes looks like this:

<OAuthV2 name='OAuthV2-GenerateAccessToken-CC'>
  <Operation>GenerateAccessToken</Operation>
  <ExpiresIn ref='flow.variable'>1800000</ExpiresIn>
  <RefreshTokenExpiresIn>691200000</RefreshTokenExpiresIn>
  <SupportedGrantTypes>
    <GrantType>client_credentials</GrantType>
  </SupportedGrantTypes>

  <!-- name of variable that specifies the requested grant type -->
  <GrantType>request.formparam.grant_type</GrantType>

  <Attributes>
    <Attribute name='grant_type'
               ref='request.formparam.grant_type'
               display='true'>UNDEFINED</Attribute>
    <Attribute name='cookie'
               ref='variable_name_that_contains_cookie_to_store'
               display='false'>UNDEFINED</Attribute>
  </Attributes>

  <GenerateResponse enabled='true'/>

</OAuthV2>
 

You can see the Attributes element - each child element called Attribute there specifies a piece of data to attach to the token when it is minted. Read more about custom attributes in these places:

• a question on community
  
• the product documentation

When the token is presented back for validation at some later point, then the metadata you have stored as custom attributes is available to the proxy in context variables. So you could do something like:

1. OAuthV2/VerifyAccessToken
2. AssignMessage - to assign a cookie header
3. ...invoke target....

Does this make sense?

[DChiesa]

is there a way we can provide the TTL for each entry in this cache object and then invalidate that entry from cache object.

Yes

The PopulateCache policy includes a property that allows you to specify the TTL: ExpirySettings.

Check the documentation. Here is an example:

<PopulateCache name="Populate-Cache-1">
    <CacheKey>
        <Prefix>external-tokens</Prefix>
        <KeyFragment ref="request.queryparam.token"/>
    </CacheKey>
    <!-- Omit this element if you're using the included shared cache. -->
    <CacheResource>tokens</CacheResource>
    <Scope>Exclusive</Scope>
    <ExpirySettings>
        <TimeoutInSec>3600</TimeoutInSec>
    </ExpirySettings>
    <Source>theVariableContainingTheThingToCache</Source>
</PopulateCache>

You also mentioned KVM. KVM is different than Cache. The KVM is intended to provide a persistent store. It also is wrapped with a cache, but it is not a simple cache.

So take care to choose which one you will use.

[#6]

@Dino

Thanks .Could you please let me know what is the load this cache can support ,as there would be lot of accesstokens and we are planning to go for a 13 node cluster for deployment in production . Is there a need to do any other setting as well .?