MVC App not signing AuthN requests when authenticateRequestSigningBehavior="Always"

[Hubcrawler]

Nuget Package: Sustainsys.Saml2.Mvc V2.8.0

Excellent lib and made development very quick. I have successfully used this for SSO and SLO against OKTA. Now I'm trying to use it against our production IDP vendor but they require signing of AuthN requests. I have tried setting authenticateRequestSigningBehavior="Always" in the Sustainsys.Saml2 web.config element but inspection of the outgoing AuthN requests shows that no signing information is present. I have tried adding wantAuthnRequestsSigned="true" to the IdentiyProvider but still not seeing a signing of the AuthN request. I have a self-signed certificate (public/private keys) referenced in the serviceCertificates and this works when testing against OKTA (which does not require AuthN requests to be signed but does use it for SLO).

Wondering what I'm missing to get the signature/algorithm to appear in the outbound AuthN request?

Additional info

• .Net Framework: net472
• .Net Framework installed: 4.8.04084
• Version of Asp.Net MVC: 5.2.7

[mjorrens1]

I am working on a similar project with the HttpModule and a WebForms application along with the new version of the application in AspNetCore.

Anyway, is the cert from the production IdP vendor in the metadata like it is in the Okta metadata? If not, you would need to physically add it to the IdP with the line (from AspNetCore but you can translate to web.config):

idp.SigningKeys.AddConfiguredKey(new X509Certificate2("[name of okta cert].cert"));

[Hubcrawler]

Thanks for the heads up.

Aye it is and using the library in my MVC app the pertinent parts of the web.config are:

Today I was re-reading the docs and it looks like signing of an AuthN request is not planned and left up to the library user to implement. Can anyone confirm this is the case? Thanks a bunch.

[AndersAbel]

If there is a service certificate configured with usage signing and authenticateRequestSigningBehavior is set to Always it will sign.

The code might be a bit confusing because the signing is done by the binding, not by the SignInCommand. The reason is that for messages sent over POST a normal XML signature is used, but for Http Redirect, the signature is done in the query string.

[Hubcrawler]

Hey there and thank you for the follow up. I totally missed the fact that the signing defaults to HTTPRedirect when a "binding" is not specified in the web.config (and therefore the signing was in fact in the URL) and apologize for that.

I'm trying to test it via POST (as the IDP has an issue with the redirect binding) and I believe I have the correct configuration and show the pertinent pieces below:

Even though I've set the binding="HttpPost" the AuthN is still sent out as a redirect. The IDPs config file has the following bindings: If I remove the HTTP-Redirect binding in the IDP metadata file the library sends out the request as a POST. My question then does the library use the first binding it finds and ignores the "binding" setting in the XML or am I missing something else? I'm using the library in an MVC app (and the built-in Saml Controller) so all the config is done via the web.config with no actual coding pertaining to this. Thanks in advance.

[AndersAbel]

If you load Metadata (and by specificying metadataLocation that happens, even if loadMetadata=false), the Metadata options take precedence over anything configured.