IBM Verify

IBM Verify

Join this online user group to communicate across Security product users and IBM experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

  • 1.  IDMappingExtUtils.getIDMappingExtCache

    Posted Fri July 12, 2019 11:04 AM
    Hi,

    We are using IDMappingExtUtils.getIDMappingExtCache() in an oauth context to store some information that needs to be injected along with every incoming oauth request.

    We are wondering how does that cache works in a clustered environment. We have not seen any table in the runtime database that would allow sharing that cache between the different appliances in the cluster.


    Could someone knowlegeable explain to us how exactly this cache works in a clustered environment? Can we rely on it ?

    Regards,
    André

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


  • 2.  RE: IDMappingExtUtils.getIDMappingExtCache

    Posted Mon July 15, 2019 01:09 AM

    Hi Andre, 

    The IDMappingExtCache is backed by the HVDB. In a clustered environment the internal HVDB is managed by the cluster to replicate across masters, or if the HVDB is external then HA is up to the external DBMS. 

    So yes, you can rely on this cache being consistent across nodes in a clustered environment. 

    I hope this helps with your understanding.

    Thank you
    Leo



    ------------------------------
    Leo Farrell
    ------------------------------

    Original Message


  • 3.  RE: IDMappingExtUtils.getIDMappingExtCache

    Posted Mon July 15, 2019 02:26 AM
    Hi Leo,

    Thank you for your input.

    Before asking the question to the community, I checked the HVDB database but I was unable to find a table where that cache could be stored. Just for information, do you have any idea of the table/field used for that cache ?

    Thanks for clearing that point, for a moment we were afraid that that cache could have been local to the appliance!

    Regards,
    André

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

    Original Message


  • 4.  RE: IDMappingExtUtils.getIDMappingExtCache

    Posted Mon July 15, 2019 03:33 PM

    Hi André, 

    For reference the table is DMAP_ENTRIES. 

    Thank you



    ------------------------------
    Leo Farrell
    ------------------------------

    Original Message


  • 5.  RE: IDMappingExtUtils.getIDMappingExtCache

    Posted Tue July 16, 2019 04:26 AM
    Hi André,

    For OAuth, there is also the possibility to associate custom data with a grant (lookup via stateId).  This data can be stored and retrieved in the pre- and post- token mapping rules.  I wonder why you are not using this and prefer the IDMappingExtCache?

    I think use of either is OK but just interested in decision.

    Thanks... Jon.


    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------

    Original Message


  • 6.  RE: IDMappingExtUtils.getIDMappingExtCache

    Posted Tue July 16, 2019 04:34 AM
    Hi Jon,

    We do associate custom data/attributes to the grant in other OAuth use-cases but for this particular requirement the size limit was what made us switch to IDMappingExtCache.
    Custom attributes size cannot exceed 256 bytes (if I remember correctly) and the data we want to cache is a JWT that is always bigger than that.

    We cache the JWT for avoiding having to regenerate it on each incoming OAuth request. The JWT will only be regenerated when a refresh token is used, as we configured the JWT validity to be the same as the access token lifetime.


    Thank you both for your inputs!

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

    Original Message


Related Content