sha256 and SAMLv2.0 for .NET4 version 2.5.0.0

I’m starting a refactor of our assertion consumer service because we have moved to AWS and are wanting to run our site behind a load balancer.
Our version is 2.5.0.0, our .NET version is 4.6 (We haven’t experienced any issues to date using this with 4.6).
Mainly I’m needing to replace the IIDCache implementation and alter how we store idP providers—our site is multi-tenant—and we utilize the low level methods of this library.

I also have a new client wanting sha256. No problems there. I’ve tested using the supplied example SHA256Signature.

The main question is, am I using the latest version of this library?
In this Post it says:
For .NET 4.0 and above, SHA-256, SHA-384 and SHA-512 support is, for the most part, built into the .NET framework. The only requirement is to register the cryptographic algorithm which is done automatically if using the .NET 4.0 version of the ComponentSpace.SAML2 DLL

I’m still having to register like the following for sha256 to work:
CryptoConfig.AddAlgorithm(
typeof(RSAPKCS1SHA256SignatureDescription),
"<a href=“http://www.w3.org/2001/04/xmldsig-more#rsa-sha256");">http://www.w3.org/2001/04/xmldsig-more#rsa-sha256”);

This seems to work just fine, but it leads me to believe I may not have the latest version of this library.

Finally, back to the IIDCache implementation, I was planning on having a job clear stored assertions after expiration to maintain the validity of CheckForAssertionReplay, and to keep the data from growing forever. Any recommendations about this?

Thanks for a great product that has served us for a couple years now with no issues.


The current version, as of November 2015, is 2.6.0.9. Please note that the version you have does include support for SHA-256 but requires you to register the algorithm as you’ve shown. With the later versions this registration is handled automatically. Please contact support@componentspace.com if you’d like to upgrade to the latest version.
Are you storing the ID cache in a database? If so, you could schedule a maintenance job to clear the cache of expired IDs everything night or so. Please note that every SAML assertion should have a unique ID so expired IDs in the cache won’t affect SAML SSO. It’s just a storage overhead issue.
Thank you for your kind words. :slight_smile: