Hello ISAMers,
When trying to access an OAuth protected ressource we inject a http header containing a JWT with useful information for the backend api's.

We are running into a very strange issue that we don't understand at all, and we hope someone will be able to help us understand what is this black magic.

It seems that the first time an access token is used and that the following code is executed in the POSTToken mapping rule the header is correctly inserted:

if (request_type == "resource" && state_id != null) {
    trace(IN_TYPE, mapping_rule_name, "resource access, trying to add attributes to STSUU", addOpts);

    //Get a stored value
    var cache = IDMappingExtUtils.getIDMappingExtCache();
    jwtToken = cache.get(state_id);

    trace(LOG_TYPE, mapping_rule_name, "GOT TOKEN FROM CACHE: " + jwtToken, addOpts);

    stsuu.addContextAttribute(new Attribute("jwt", "urn:ibm:names:ITFIM:oauth:response:attribute", new String(jwtToken)));

    stsuu.addContextAttribute(new Attribute("tagvalue_always",
        "urn:ibm:names:ITFIM:oauth:response:attribute", "username,access_token,oauth_token_client_id,authorized,scope,client_type,expires,jwt"));

    trace(OUT_TYPE, mapping_rule_name, "resource access, session attributes added STSUU: " + stsuu.toString(), addOpts);
}​

The issue we are running into is that when we modify the JWTtoken stored in the IDMappingExtCache the logs show that we retrieve the new JWT value from the cache and that we insert it correctly in the STSUU but webseal is still injecting the previous value of the JWT!

Is there any hidden cache somewhere that makes webseal cache a oauth response attribute for an specific oauth access token ?

Thanks in advance to anyone that could help us understanding what we are doing wrong here.

------------------------------
André Leruitte
------------------------------

So after spending a bit more time we finally managed to find the source of this "not so hidden" cache.

The cache was being made at webseal level, because of the following stanza:

[oauth-eas]
# The maximum number of OAuth 2.0 bearer token authorization decisions to cache.
# This EAS has a built in cache for storing authorization decisions so that
# repeated use of the same OAuth 2.0 bearer token does not require repeated
# authorization requests. Bearer token decisions can be cached because they do not
# require signing of the request, unlike OAuth 1.0 requests. The lifetime of the
# cache entry is based on the Expires attribute returned in the STS. If this
# attribute is not returned, the decision will not be cached.
#
# This EAS implements a Least Recently Used cache, meaning the decision
# associated with the least recently used bearer token will be forgotten when a
# new bearer token decision is cached. A cache-size of 0 will disable caching of
# authorization decisions
cache-size = 20​

We configured the cache-size to 0, and we now have no issue refreshing the JWT header with a new value.

------------------------------
André Leruitte
------------------------------