We run a Service Provider SSO for a client who is the Identity Provider. We recently upgraded our webserver from Windows Server 2008 R2 with IIS 7.5 to Windows Server 2016 with IIS 10 we started to see the error “The SAML assertion is being replayed”. As a result, I attempted to replicate this by using the MvcExampleIdentityProvider application supplied with the software and I am seeing the same error. I was wondering if anyone has any thoughts on what could be causing this issue. I have verified through Fiddler that I (as the Identity Provider) am sending only a single assertion, but the IIS logs and the SAML Trace Logs indicate that the website is receiving multiple sometimes up to 5 duplicate assertions. I’ve attached both our IIS logs and the SAML Trace log. What’s really strange is apart form upgrading the server and IIS no changes were made to the website or SAML configuration itself. I am of the opinion that there is something in IIS that is configured wrong but I’m not sure what that would be.
Any help would be appreciated.
-Nathan
Hi Nathan,
There shouldn’t be any issues with Windows Server 2016 or IIS 10. One of our test server images has this combination.
The SAML log shows the HTTP Post of the same SAML response being received three times. Each appears to be received on a separate browser session as the ASP.NET session ID is different for each.
Do you have IIS rewrite rules configured? Could these possibly be causing the duplication?
Let me know what you find. Thanks.
There shouldn't be any issues with Windows Server 2016 or IIS 10. One of our test server images has this combination.
The SAML log shows the HTTP Post of the same SAML response being received three times. Each appears to be received on a separate browser session as the ASP.NET session ID is different for each.
Do you have IIS rewrite rules configured? Could these possibly be causing the duplication?
Let me know what you find. Thanks.
Thank you, I will look into the IIS Rewrite rules and see what we have. It's interesting that the response is being received from different browser sessions.
-Nathan
There shouldn't be any issues with Windows Server 2016 or IIS 10. One of our test server images has this combination.
The SAML log shows the HTTP Post of the same SAML response being received three times. Each appears to be received on a separate browser session as the ASP.NET session ID is different for each.
Do you have IIS rewrite rules configured? Could these possibly be causing the duplication?
Let me know what you find. Thanks.
Thank you, I will look into the IIS Rewrite rules and see what we have. It's interesting that the response is being received from different browser sessions.
-Nathan [/quote]It does look like we are using URL Rewrite rules to enforce https by redirecting http traffic to https. I'm unsure if that could be the problem as we had that enabled on our 2008 r2 box as well. but I will look into it.
-Nathan
Let me know what you find. Thanks.
I can verify that the IIS Rewrite is not causing this problem. We utilize the rewrite function in our 2008 r2 setup, but I've also disabled that functionality to test on the 2016 server with no luck.
I am being asked to verify that we are using the latest version of the ComponentSpace.SAML2.dll, we are currently using version 2.8.8.0. Can you verify that this is the latest version of if there is a newer version we can update to.
The latest version is 4.1.0.
You’ll find the release notes at:
https://www.componentspace.com/documentation/saml-for-asp-net/ComponentSpace%20SAML%20for%20ASP.NET%20Release%20Notes.pdf
Please contact support@componentspace.com for upgrade options.
You'll find the release notes at:
https://www.componentspace.com/documentation/saml-for-asp-net/ComponentSpace%20SAML%20for%20ASP.NET%20Release%20Notes.pdf
Please contact support@componentspace.com for upgrade options.
Sorry, it's been a bit, but we think we've narrowed down where the problem is. We have our site set up to require SSL and the Client Certificates set to Accept, as it's part of our site's authentication methods. We've noticed that when we set the Client Certificates to Ignore we no longer get the replay attack. I'm wondering if you have any thoughts on why this might be.
Thank you,
Nathan
Hi Nathan,
Thanks for the update. It’s good to hear you’ve narrowed down the cause. We haven’t heard of any issues related to client certificate authentication.
I tested this here using IIS 10 with Require SSL checked and Accept client certificates selected. The browser prompted me to select a client certificate and, once I did that, SSO and SLO worked as expected without any errors.
Have you tried this on a different server?
Please keep us posted.