Metadata export

SAML for ASP.NET Core
1

Hi,

I’m currently trying to migrate our SAML portal from v2.0.6 to v3.7.0 and I’m running into some issues with our custom code. First a brief background.AbstractSamlConfigurationResolverAbstractSamlConfigurationResolverAbstractSamlConfigurationResolver

1. We have bot a local SP and a local IDP. These are defined in the configuration via appSettings.json. The local certificates are stored in Azure Key Vault and they are self-signed.
2. For our local SP we support a vast number of partner IDP’s and we need a quite dynamic configuration support. Therefor we have a custom ISamlConfigurationResolver that is derived from AbstractSamlConfigurationResolver. This custom ISamlConfigurationResolver resolves our local IDP and SP from the configuration, while the partner IDP’s are stored in a database. The partner IDP’s metadata is persisted by serializing the PartnerIdentityProviderConfiguration instance that is mainly obtained via MetadataToConfiguration.ImportUrlAsync.

Now to the current issue at hand.

To expose our own SP Metadata, we generate it on the fly from the current configuration. This is done in a MVC action by utilizing the ConfigurationToMetadata class.
Previously we initated a standalone ConfigurationToMetadata instance and used the Export(SamlConfiguration, X509Certificate2, X509Certificate2) function by feeding a SAMLConfiguration instance that we obtained via the ISamlConfigurationResolver.GetLocalServiceProviderConfigurationAsync(string ConfigurationID). Before export we hade to load the certificates manually via the ICertificateLoader though to feed into the Export() function.

Now the ConfigurationToMetadata has been changed and requires a ISamlConfigurationResolver and ICertificateManager instances in its constructor. Fair enough an easy change and the Export(…) function is now changed to ExportAsync(string configurationID) which means we don’t have to manually fetch the configuration and load certificates.
The problem though is that the certificates are now being validated which results in an exception for the self-signed IDP and SP certificates.
ComponentSpace.Saml2.Exceptions.SamlCertificateException : The X.509 certificate with subject name CN=xxx, O=yyy, C=SE, serial number AAAAAA and thumbprint BBBBBB failed to validate.

Is there any way to diabled the certificate validation during the configuration export to metadata format?

After some further digging it seems this might be “platform” dependent as I am running my development stack on macOS 10.15.7. The output below points to this being an issue.

The certificate failed to load using the flags MachineKeySet, Exportable, EphemeralKeySet.
System.PlatformNotSupportedException: This platform does not support loading with EphemeralKeySet. Remove the flag to allow keys to be temporarily created on disk.
at Internal.Cryptography.Pal.AppleCertificatePal.FromBlob(Byte[] rawData, SafePasswordHandle password, X509KeyStorageFlags keyStorageFlags)
at System.Security.Cryptography.X509Certificates.X509Certificate…ctor(Byte[] rawData, String password, X509KeyStorageFlags keyStorageFlags)
at ComponentSpace.Saml2.Certificates.CertificateLoader.LoadCertificate(Byte[] certificateBytes, String certificateFile, String certificatePassword)
ComponentSpace.Saml2.Certificates.CertificateLoader: Debug: The certificate failed to load using the flags MachineKeySet, Exportable, EphemeralKeySet.

2

In v3.7.0 we introduced support for X.509 certificate validation. The default validation checks that certificates haven’t expired.

Is it possible that the certificate you’re trying to export has expired?

You can turn off this check at application start-up as follows.


using ComponentSpace.Saml2.Certificates;

services.Configure(options =>
{
options.EnableNotAfterCheck= false;
});

// Add SAML SSO services.
services.AddSaml(Configuration.GetSection(“SAML”));



The EphemeralKeySet flag isn’t supported on macOS. However, we log this but fall back to attempting to load the certificate without specifying this flag. This shouldn’t cause any issues.

If there’s still an issue, please enable SAML trace and send the generated log file as an email attachment to support@componentspace.com mentioning your forum post.

https://www.componentspace.com/Forums/7936/Enabling-SAML-Trace

3
[quote]
ComponentSpace - 8/30/2021
In v3.7.0 we introduced support for X.509 certificate validation. The default validation checks that certificates haven't expired.

Is it possible that the certificate you're trying to export has expired?

You can turn off this check at application start-up as follows.


using ComponentSpace.Saml2.Certificates;

services.Configure(options =>
{
options.EnableNotAfterCheck= false;
});

// Add SAML SSO services.
services.AddSaml(Configuration.GetSection("SAML"));



The EphemeralKeySet flag isn't supported on macOS. However, we log this but fall back to attempting to load the certificate without specifying this flag. This shouldn't cause any issues.

If there's still an issue, please enable SAML trace and send the generated log file as an email attachment to support@componentspace.com mentioning your forum post.

https://www.componentspace.com/Forums/7936/Enabling-SAML-Trace
[/quote]

It was an expired certificate that caused the validation failure so you were spot on in that analysis. Thanks a million for catching that.

As a side question regarding certificate handling if I may. Does the order of certificates in the configuration affect their usage?

I need to rotate my certificates and figured I would list both the old and new certificates in the configuration and my metadata. The plan is to roll out the metadata change and after a while when all partner IDP's and SP's should have reloaded or metadata, remove the secondary certificate to stop its usage. It would then be beneficial if both certificates could be used for validation, but only the old and first listed certificate is used for signing and encryption during the rollover period.
4

If multiple partner certificates are configured, we attempt to verify the signature using the certificates in the order they appear.

If multiple local certificates are configured, we use the first certificate for signature generation.

More information may be found at:

https://www.componentspace.com/Forums/8238/Certificate-Guide

5
[quote]
ComponentSpace - 8/31/2021
If multiple partner certificates are configured, we attempt to verify the signature using the certificates in the order they appear.

If multiple local certificates are configured, we use the first certificate for signature generation.

More information may be found at:

https://www.componentspace.com/Forums/8238/Certificate-Guide
[/quote]


6

Sorry, did you have a question?

7
[quote]
ComponentSpace - 8/31/2021
If multiple partner certificates are configured, we attempt to verify the signature using the certificates in the order they appear.

If multiple local certificates are configured, we use the first certificate for signature generation.

More information may be found at:

https://www.componentspace.com/Forums/8238/Certificate-Guide
[/quote]

I think an extra space in the link made it dead https://www.componentspace.com/Forums/8238/Certificate-Guide

I've gone over that document before, but unfortunately it is missing the key information you just provided. "If multiple local certificates are configured, we use the first certificate for signature generation.".


8

Sorry about the link. I’ve corrected that.

Thanks for the feedback. I’ll see that this is made clearer in the guide.