Updating/refreshing SAMLConfiguration

SAML for ASP.NET
1

What’s the proper way to refresh the SAMLConfiguration when acting as the SP? When the ACS endpoint is hit, there isn’t a way to know ahead of time which “configuration” to use. So, that mean that the SAMLConfiguration needs to be already configured with all possible partner IdP configs, right? Whereas, when acting as the IdP, it’s typical to know the tenant ahead of time and refreshing only that particular tenant’s config is relatively easier. Hopefully I make sense, if not, I can try to clarify the scenario further.

2

In many scenarios, SAML configuration isn’t dynamic. Usually configuration information has to be exchanged between yourself and the partner as part of setting up the SSO federation.
It would be unusual to receive a SAML response at your assertion consumer service from an unknown partner IdP and then dynamically update your configuration to include the partner IdP.
Updating existing SAML configuration is a more common process. For example, the partner’s certificate may need to be updated.
In both cases, SAML configuration should be set programmatically.
http://www.componentspace.com/Forums/38/Specifying-the-SAML-Configuration-Programmatically
For multi-tenancy applications, you need to identify the tenant before specifying which SAML configuration to use.
This is true whether acting as the IdP or SP.
http://www.componentspace.com/Forums/51/SAML-MultiTenancy-Applications
I may not have understood your scenario so please ask again if that’s the case.

3
[quote]
ComponentSpace - 1/29/2017
In many scenarios, SAML configuration isn't dynamic. Usually configuration information has to be exchanged between yourself and the partner as part of setting up the SSO federation.
It would be unusual to receive a SAML response at your assertion consumer service from an unknown partner IdP and then dynamically update your configuration to include the partner IdP.
Updating existing SAML configuration is a more common process. For example, the partner's certificate may need to be updated.
In both cases, SAML configuration should be set programmatically.
http://www.componentspace.com/Forums/38/Specifying-the-SAML-Configuration-Programmatically
For multi-tenancy applications, you need to identify the tenant before specifying which SAML configuration to use.
This is true whether acting as the IdP or SP.
http://www.componentspace.com/Forums/51/SAML-MultiTenancy-Applications
I may not have understood your scenario so please ask again if that's the case.

[/quote]

Thanks for the info. On a slightly alternate, but related topic, is setting the SAMLConfiguration threadsafe? How does it work across multiple concurrent request threads?
4

No, it isn’t thread safe.
If you update the SAML configuration whilst SSO requests are being processed it’s possible these requests will fail, depending on what changes you make. Subsequent SSO requests should succeed.

5
[quote]
ComponentSpace - 1/30/2017
No, it isn't thread safe.
If you update the SAML configuration whilst SSO requests are being processed it's possible these requests will fail, depending on what changes you make. Subsequent SSO requests should succeed.
[/quote]

Would changing the SAMLConfiguration.ConfigurationID to different tenants cause problems between requests to different tenants with different configurations? If so, that sounds like a problem.
6

No, changing the ConfigurationID is safe.
It’s stored in the internal SAML state which is different for each user.
You can safely be processing multiple SSO requests for different tenants without any issues.

7
[quote]
ComponentSpace - 1/30/2017
No, changing the ConfigurationID is safe.
It's stored in the internal SAML state which is different for each user.
You can safely be processing multiple SSO requests for different tenants without any issues.
[/quote]

Ok, phew! That's what I was worried about. Thanks for the clarification.
8

You’re welcome.