[IdP] Unable to cast object of type 'System.Security.Cryptography.RSACng' to type 'System.S

Forge Component
(37)
Published on 4 Aug (2 weeks ago) by Telmo Martins
37 votes
Published on 4 Aug (2 weeks ago) by Telmo Martins

I asked Outsystems support to upgrade the platform to the latest stable (Version 11.0.539.0). Since then, when I logout the webapp, I'm getting:

UNABLE TO PROCESS REQUEST
Unable to create SAML request

In the Sevice Center, I found:

Unable to cast object of type 'System.Security.Cryptography.RSACng' to type 'System.Security.Cryptography.RSACryptoServiceProvider'.


More details below. Any ideas?
Thanks in advance.

There's some kind of error on underlying .NET libraries when dealing with encryption keys, so as first effort, I'd try re-generating IdPConnector keystore from configuration pages.

Why? As System.Security.Cryptography libraries are part of .NET libraries, I'm guessing platform update has bumped up the version of underlying .NET libraries. Therefore I'm guessing you are having keystore stored in IdP entity, which is most probably generated using the other RSA implementation.

From this link you can see why I suspect this and the error is happening - these two RSA algorithm implementations (RSAcng/RSACryptoServiceProvider) are not replaceabe between each other:

https://docs.microsoft.com/en-us/dotnet/api/system.security.cryptography.rsacng?view=netframework-4.8

Also, spying from NuGet pages, ITfoxtec.Identity.SAML2 library was updated a month ago, and as it's instantiating the RSA implementation which is failing, I'd presume it's updated as well. If re-generating keystore does not help, SAML_Utils extension should be looked at. 

For this, I'd first try recompile/republish SAML_Utils extension through integration studio. If this does not solve your problem, then maybe updating IdP from Forge (if not already done) could help. After that, it probably requires digging in to extension C# code to solve the problem.

Hi Mikko,

Thanks for your quick response.

I just tried the first two options:

First, re-generating the keystore. After that, setting up the relying party trust in my ADFS with the updated metadata, adding claims, etc. Login worked, Logout didn't. It is wierd, isn't it? Only 'logout' because the encryption algorithm should also works in the Login.

Second, in Integration Studio, I tried re-publishing (compiling) SAML_Utils and then, updating the references in IDP, publishing all the consumers of the application. The app was updated from Forge was.

In the end, it seems that C# code is my last chance.


Hi Emiliano,

Login does not requires to "work" with the SP keystore unless the assertion is encrypted or Authn is configured to be signed.

I have also access to an environment with that version, when I got the chance I'll also try to check it out and reproduce the error.

Regards.

Hi Telmo,

Thanks for the explanation.


Hi Emiliano,

Meanwhile were checking the error and also checking the 3rd party source code where the error was occurring and were able to reproduce it (both on a server app and also locally) and start again to successfully generate the logout request. At least from my tests since .net 4.6.2, when the keystore is loaded from the extension, the property used by the 3rd party ITfoxtec.Identity.SAML2 library was the one already that since 4.6.2 starts to return the new crypto implementation and causing the error. The fix was to set the correct sign algorithm to the 3rd party according to the crypto implementation that's being used at the moment (the old or the new one).


If you still face issues please let me know.


Regards.

Hi Telmo,

Once again, thanks for the explanation. When you said:

"The fix was to set the correct sign algorithm to the 3rd party according to the crypto implementation that's being used at the moment (the old or the new one)."

Is it something that I should manage from the component's code? Should we wait for some component update?

I'm new with Outsystems and also with this sort of issues.

Thanks!

Hi Emiliano,

The component was already updated yesterday. You just need to update it from forge and the error should not happens any more.

Regards.

Hi Telmo,

Thanks!

I just did it. The good news: the IDP component is not crashing. The bad, my ADFS is not accepting the LogoutRequest any more. I compared it with an old one and it seems the secure hash algorithm has changed (it was sha-256 and now looks like sha-1). Find below a piece of the saml2p:LogoutRequest:

<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<Reference URI="#id_c1993d5c86c04eeaba460bd60c427944">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>0p2a1EATdcFFX41idDOAS+RdqQE=</DigestValue>
</Reference>
</SignedInfo>

I could not find a way to update it in the configuration. Should I change it from the ADFS side instead?

Thanks!

Hi Emiliano, 

Yes, it changed automatically when using the new crypto implementation. Usually the idp servers adapts automatically but if it's not the case, then probably in Adfs is necessary to manually change the configuration from sha256 to sha1 in the console configuration. 

Regards. 

OK.
I did and now the ADFS generated the success LogoutResponse but in the IDP console I got:

"Signature validation failed."

Should I regenerate the Keystore o re-import metadata between IDP and ADFS?

I feel closer :-). Thanks!

Hi Emiliano, 

I'm assuming that error is regarding the validation of LogoutResponse in IdP side. That's weird because probably you should have the same error at Login time,maybe its caused by another reason. What's the whole message error from the service center log? 

As quick workaround you can also go to the IdP configuration page, open the advanced options and activate the option Allow unsigned logout responses. 

Regards. 

Shame on me but I could not find any error message in the service center. Should I change de logging level may be?

The good news is your workaround (with sha-1 and unsigned logout) worked! :-D

Thanks!

Hi Emiliano,

Nice it worked with the workaround. However if that error is not on the log then then the message validation fails just because the validation itself fails and not due some exception.

If possible can you provide the saml logout response (you can get it from the Saml message log screen) and the idp server public certificate for further analysis.

Regards.

Hi Telmo,

Find attached the SAML logout response and the .p12 certificate from IDP server (I coldn't find the public one, can you use it? I have no password).

Thanks!

Hi Emiliano,

The response is not signed (at least within the message). From the screen that you retrieve it whats the value for the entry above as "Saml Message Bind"? 

If it's HTTP-POST then that workaround it's the real solution. If it's HTTP-Redirect then you need to provide the whole query string produced by ADFS when it redirects the browser back to the idP component, the fastest way to get it is to repeat the test with the browser dev tool open and copy the whole URL when the browser is redirected back to the IdP component with the LogoutResponse (deflated with B64) and not directly in XML/B64.


Regarding the certificate, actually was talking about the public idp server certificate that you can download from the IdP component, namely:


Regards.