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

[Jim From Test]

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:

<cache clearOnFlush="true" memoryStoreEvictionPolicy="LRU" diskExpiryThreadIntervalSeconds="3600" diskPersistent="false" maxElementsOnDisk="10000000" diskSpoolBufferSizeMB="30" overflowToDisk="false" timeToLiveSeconds="60" eternal="false" maxElementsInMemory="10000" name="samlcache">
</cache>

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]

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. 

[Jim From Test]

Thanks Pete for your timly rely - I wrote this replay last week but just relized it never got Posted until this morning....

We are calling processSAMLResponse() in the same .cfm the IDP calls. However - the cfloginuser called after the processSAMLResponse() happens elseware.

In the .cfm with processSAMLResponse() we do some processing (authentication on our side making sure that incoming user has an acount etc). If the incoming SAML request passes our authentication we build an access token send it over to our regular login application. The app sees the token for this user and does all the login stuff including calling cfloginuser.

We architected this so processSAMLResponse() is actually in a different site (let's call it a semiprivate site). So when we build the login token and when we send it to our regular application (private site), it's Application.cfc sees that for this new session there's no login it'll look for the login token before displaying a login page.

I'm thinking - do you know if processSAMLResponse() need to be in the same site that calls cflogin?

Even so, I would think the cache should have cleared, with the way it's currently architected....

Any additional thoughts? Again - thanks for your help.

[willm97847934]

Hi folks I have a similar problem trying to handle an IDP-initiated SSO (from Azure). CF breaks this with it's 'Possible replay attack' error.

I'm sure there's a simple answer to this? Please help.

Current work-around is to <cfcatch> it and redirect to my ACS and have the SP initiate. Certainly not ideal as the user is already authenticated(!).

Many thanks in advance

Will

[willm97847934]

Duh, sorry i found the setting in cfadmin for the SP. Sorry - delete this