I am rebuilding my client’s website, migrating from ASP.NET WebForms to MVC. In the MVC website, I have changed to reference the latest ComponentSpace NuGet package, v3.4.0 and .NET Framework 4.7.2. After rewriting the user authentication to use ASP.NET Identity with OWIN and MVC Controller Actions, I’m seeing “Invalid Algorithm Specified” when attempting to call,
SAMLMessageSignature.Generate(XmlElement xmlElement, AsymmetricAlgorithm signingKey, X509Certificate2 x509Certificate)
I’ve kept the calls to ComponentSource the same between the two websites. The original website works locally with v2.5.0. Am I possibly missing some required setting in the new website?
When I inspect the X509Certificate2 instance that get’s loaded, I see the following:
SignatureAlgorithm: sha1RSA, value = 1.2.840.113549.1.1.5
PrivateKey SingatureAlgorithm: http://www.w3.org/2000/09/xmldsig#rsa-sha1
KeyExchangeAlgorithm: RSA-PKCS1-KeyEx
We now default to SHA-256 signatures. In earlier releases from a few years ago the default was SHA-1.
You need to ensure the cryptographic service provider (CSP) associated with the private key supports SHA-256 signature generation.
As an experiment, try using the idp.pfx file that we ship when calling SAMLMessageSignature.Generate. If this works, it confirms the issue is specific to your certificate/private key.
Assuming that’s the case, please take a look at the following forum post which explains how to update your PFX file to specify the correct CSP.
https://www.componentspace.com/Forums/1578/SHA256-and-Converting-the-Cryptographic-Service-Provider-Type
If there’s still an issue, please enable SAML trace and send the generated log file to support@componentspace.com mentioning your forum post.
https://www.componentspace.com/Forums/17/Enabing-SAML-Trace
I have verified the above using the sp.pfx file from the Examples NuGet package. The call to SAMLMessageSignature.Generate() now completes successfully.
Do you mean that SHA-256 is the minimum algorithm supported when you say its the default or can I change it to use SHA-1?
I can look into changing the sp.pfx file, but I’m not sure if I will be able to obtain a SHA-256 version of the CER file provided by the Identity Provider. Do you expect that I’d need to obtained an updated version of the CER file used for Assertion and Logout?
Thanks for the help
You can change it to SHA-1 but we recommend SHA-256 which is why we set this as the default. SAMLMessageSignature.Generate has a number of overloads where you can specify the signature algorithm etc.
The private key and certificate you supply as parameters to SAMLMessageSignature.Generate will belong to you rather than a partner provider.
Updating the CSP won’t affect the private and public key values. Its only impact is adding support for SHA-256 signatures.
Is your site the identity provider or service provider?
Are you calling SAMLMessageSignature.Generate to sign SAML authn requests and/or SAML logout messages?
Changing the CSP for your private key and generating SHA-256 signatures won’t have any impact on the partner provider other than they need to be able to verify SHA-256 signatures.
My website is the server provider. I have successfully generated the SP PFX file as the links above outlined. I’m currently making progress and worked with the Identity Provider to resolve a couple of hard-coding issues on their side.
I’m calling SAMLMessageSignature.Generate() for the Authentication request which is working with the new SP PFX file. The user is able to log and the assertion is processing as expected.
For the Logout, I’m calling the following, not using SAMLMessageSignature.Generate() to sign the XML. However, in this implementation, when I call LogOut, SingleLogoutService.ReceiveLogoutMessageByHTTPRedirect() immediately errors with “No SAML message query string parameter in HTTP Redirect”. Has the user of this function changed in the new versions? I would like to switch to you
public bool LogOut()
{
var idpCertificate = GetIdpCertificate();
SingleLogoutService.ReceiveLogoutMessageByHTTPRedirect(
new HttpRequestWrapper(CurrentHttpRequest),
out XmlElement logoutMessage,
out string relayState,
out bool isRequest,
out bool signed,
idpCertificate.PublicKey.Key);
if (isRequest)
{
LogOutCmsUser();
SendLogoutResponse(relayState);
return false;
}
return true;
}
private void SendLogoutResponse(string relayState)
{
XmlElement logoutResponse = CreateLogoutResponse();
X509Certificate2 spCertificate = GetSpCertificate();
SingleLogoutService.SendLogoutResponseByHTTPRedirect(
new HttpResponseWrapper(CurrentHttpResponse),
BaseIdpLogoutUrl,
logoutResponse,
relayState,
spCertificate.PrivateKey,
null);
}
The method hasn’t changed. It’s complaining that there’s no SAML request or SAML response query string parameter.
If you enable SAML trace, you’ll see the HTTP request that’s been received.
https://www.componentspace.com/Forums/17/Enabing-SAML-Trace
Alternatively, use the browser developer tools to take a look at the HTTP traffic.
If the SAML request or SAML response query string parameter is missing, it might mean the IdP is performing a simple redirect to you rather than sending a SAML logout message.
You should confirm with them whether they support SAML logout.
It appears the SLO code from the original website was never completed by the original developer and I was missing that there should be a separate InitiateSLO call tied to the button click. Due to my lack of understanding, I had made an assumption that the Request/Response check of SingleLogoutService.ReceiveLogoutMessageByHTTPRedirect() somehow provided this behavior. I also found that I should be referring to the Low Level API examples for how this was originally implemented. I completed the code from the example and was able to get Login and Logout completely functional in my new MVC website.
I also really liked the minimal code of the provided MVC example, so I changed the code to use saml.config and the SAMLServiceProvider class. This is a much cleaner solution.
Thanks for the guidance and for bearing with me!
(edit: missing words)
I’m pleased you moved to the SAML high-level API. This is a much better option moving forward. Thanks for the update.