CF2021 SAML Login/Logout Cache not Clearing (possible replay attack...)

Question

We're running ColdFusion2021 Enterprise and attempting to use the SAML feature where our application is the SP and a customer is the IDP using Azure AD.

When we first called ProcessSAMLResponse() it authenticated. Subiquestial calls to ProcessSAMLResponse() are now getting this error: "Possible replay attack occurred as there is no login/logout information associated with this request.".

We suspect this is related to the SAMLcache and we feel it's not clearing when it should.

In the SP Configuration - the Request Store setting we've tried both the "Default" and "Cache" settings. After it started failing with the "Default" we edited ".../lib/auth-ehcache.xml" and changed the setting: "timeToLiveSeconds" from 600 to 60. Here's the xml:

After making this change we stopped and restarted the ColdFusion2021 service.

Also, we thought, auth-ehcache.xml might not have the correct file permissions - but it looks correct and tied to "cfuser".

Does anyone have any ideas? Anyway to inspect ehcache and/or clear is manually (or via code)? Is there another xml setting we should be adjusting? The error almost seems like a warning message? Is there a way to safely bypass it without compromoizing the authentication process.

Many thanks in adance for any suggestions.

pete_freitag · Accepted Answer

It sounds like you might be calling processSAMLResponse() on a page that is not the ACS url. When the IDP authenticates you it POSTs back to the ACS url information that processSAMLResponse is looking for. Based on the error message it sounds like that information is not there. On your ACS page, you can create a session varaible and store the relavent information about the user.

There is also the replay attack prevention feature that makes sure the SAML request id is not used more than once, which does use the ehcache to store the ids by default. I don't know of a way to inspect the ehcache, but there is probably a way to do it. You can also use Redis for the cache, and then you can inspect the redis database using a redis client if you think that is the problem.

kevinmkr2 · Answer

I recently had this same error on CF ENT install with 3 instances.  Smelled like the same issue.  Thankfully, we had already set up Redis for our caching so resolving the issue was to explicitly set the SP "RequestStore" parameter to "cache".  Note: my first (incorrect) stab was to set it to "Redis" but I believe that that value may be reserved for setups where Redis is set for session managment (I could be wrong, however).  Regardless, if you're using Redis already for caching, you don't need to bother monkeying around with EHCache replication.

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded