Dynamic SAML provider can never sign AuthnRequests (WantAuthnRequestsSigned hardcoded to false)

[jwalker-hw]

Version: 8.0.7

A SAML dynamic provider configured with SpSigningCertificateBase64 and SpSigningCertificatePassword sends unsigned AuthnRequests. The redirect to the IdP carries SAMLRequest and RelayState but no SigAlg or Signature.

As far as I can tell this can't be configured around. In SamlConfigureOptions.BuildIdentityProvider:

var idp = new SpIdentityProvider(new EntityId(provider.IdpEntityId!), spOptions, timeProvider)
{
    AllowUnsolicitedAuthnResponse = allowUnsolicited,
    WantAuthnRequestsSigned = false,
    ...
};

SPOptions.AuthenticateRequestSigningBehavior defaults to IfIdpWantAuthnRequestsSigned, nothing in the dynamic path changes it (PostConfigureSaml2OptionsForDynamic only sets up a logger and a cookie manager), and SamlProvider exposes no property that maps to either. So the condition is always false.

The certificate is loaded, and the doc comment on SpSigningCertificateBase64 says it signs "outbound SAML messages (AuthnRequests, LogoutResponses)... Required when the remote IdP expects signed requests", which is what led us to expect signing to work.

Repro

Register a saml2 dynamic provider with an SP signing certificate, start an SP-initiated sign-in, and inspect the redirect. No signature parameters.

Ask

Could SamlProvider expose the signing behavior, or could WantAuthnRequestsSigned come from the provider model? Static SP registration can reach AuthenticateRequestSigningBehavior, but dynamic providers are the whole reason we're registering IdPs per customer. If the hardcoded value is deliberate, it would help to say so in the SpSigningCertificateBase64 docs, since they currently read as though request signing is supported.

@maartenba - only because you jumped on this so fast last time. ;)

[maartenba]

Ha! Passing it on to dev team indeed, but no promises (digging into it though)

[maartenba]

Fix is coming soon 👍

[wcabus]

@jwalker-hw Duende IdentityServer v8.0.8 has been released.
This version now supports configuring the signing behavior to either Never or Always for both static or dynamic providers:

_ = isBuilder
    .AddSamlDynamicProvider()
    .AddInMemorySamlProviders([
        new()
        {
            Scheme = "saml-idp",
            DisplayName = "External Identity Provider",
            Enabled = true,
            IdpEntityId = "https://idp.example.org/saml/metadata/123456",
            SingleSignOnServiceUrl = "https://idp.example.org/saml2/sso/123456",
            SigningCertificateBase64 = "...base64-encoded cert...",
+           AuthnRequestSigningBehavior = AuthnRequestSigningBehavior.Always
        }
    ]);

[jwalker-hw]

fantastic! Thanks, friends.

[jwalker-hw]

Thanks for the quick turnaround — 8.0.8 works. AuthnRequestSigningBehavior reaches a dynamic provider and produces a signed request on both bindings.

However, when I took it to a live Okta tenant today, I hit something I can't explain. Okta has our SP certificate uploaded and "Validate SAML requests with signature certificates" enabled; entity ID and ACS match exactly. The only variable below is that toggle:

Binding	We sign	Okta validates	Result
Redirect	yes	no	assertion returned
Redirect	yes	yes	no assertion
POST	yes	yes	no assertion
POST	yes	no	assertion returned

In the failing runs, Okta parses the request, resolves the right app, evaluates its sign-on policy and authenticates the user - then never emits the SSO event and never logs a reason. My user just lands on the Okta dashboard.

I verified the signature two ways against the same certificate Okta holds.

• For Redirect, I reconstructed the signed string independently (SAMLRequest, RelayState, SigAlg, each URL-encoded) and verified with RSA.VerifyData; a tampered copy fails, so the check definitnely discriminates.
• For POST, SignedXml.CheckSignature validates the enveloped signature including canonicalization and digest. Both pass. SignedInfo is exc-c14n / rsa-sha256 / sha256 with enveloped-signature + exc-c14n transforms, and Reference URI resolves to the request ID.

So the bytes look right by every check I can run from outside. Is there anything 8.0.8 emits that a verifying IdP could legitimately reject that those two checks would miss? The things I can't rule out from here are the Signature element's position and unprefixed namespace, whether KeyInfo is expected to carry more than X509Certificate, and whether anything in the Redirect construction differs from what verifiers reconstruct. Or it may well turn out to be specific to Okta's free Integrator tier rather than to the signature??

I'd be happy to send a full unredacted request and the certificate privately.
@maartenba @wcabus

[jwalker-hw]

@wcabus
<confirmed what I had here isn't the issue - removing>

[jwalker-hw]

@wcabus - I cloned the Duende 8 + locally. I think I've ruled out a problem on your side. I think this is in Okta's court. I'll keep you posted - but unless somethign screams out to you ... don't spent more time on this.

[wcabus]

@jwalker-hw I have been looking into this today, and it might be something Okta expects to be present in the AuthnRequest: the name ID format. Tomorrow, I'm going to try to confirm my suspicion, I'll keep you posted.

[wcabus]

@jwalker-hw As I suspected, if I add the name ID format during the authentication request, Okta happily authenticates and completes the SAML flow.

For example, the following AuthnRequest using the Redirect binding works, when I add the NameIDPolicy element:

<saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" ID="id0187f5b45a8c40ea9863ef6dd311cb8a" Version="2.0" IssueInstant="2026-09-18T12:21:45Z" Destination="https://trial-#####.okta.com/app/trial-#####_app_1/exk17ozr5#####98/sso/saml" AssertionConsumerServiceURL="https://localhost:5001/federation/okta/Saml2/Acs">
  <saml2:Issuer>https://localhost:5001</saml2:Issuer>
  <saml2p:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
</saml2p:AuthnRequest>

Using the Post binding also works. Basically the same principle, but the XML then also contains the signature etc., so I won't copy that example here as its basically the same deal. Note that the Name ID format used in the AuthnRequest must match the one configured in Okta for authentication to work.

Technically, I don't think that the SAML spec demands adding the NameIDPolicy element to the AuthnRequest when signing the request: the XML element is optional. Unfortunately, Okta requires the element's presence when signature validation is enabled.
Problem is that our SAML bits currently don't provide an option to add the NameIDPolicy element. Or I didn't find it yet without resorting to some internal plumbing. I'm going to check with our engineering team if there is a way around this, or if we need to expose the ability to set this XML element.

[jwalker-hw]

@wcabus - You're exactly right. I just independently came to that same conclusion now and was coming back to write it up.
When I made the change to my locally compiled Duende 8.0+ code - I could finally do the SAML signing and login in properly. I made this change locally to prove the cause:

File: identity-server/src/IdentityServer/Internal/Saml/Sp/IdentityProvider.cs
Method: CreateAuthenticateRequest, ~line 243

- NameIdPolicy = spOptions.NameIdPolicy,
+ NameIdPolicy = spOptions.NameIdPolicy ?? new Saml2NameIdPolicy(null, NameIdFormat.Unspecified),

Finding

The emit path is already bueno. Saml2AuthenticationRequest.ToXElement calls AddNameIdPolicy, which writes the element correctly, and IdentityProvider.CreateAuthenticateRequest already assigns NameIdPolicy from spOptions.NameIdPolicy.

The missing bit is upstream of both. SPOptions.NameIdPolicy has no initializer, so it defaults to null, and SamlConfigureOptions.Configure never assigns it. That method sets ModulePath, EntityId, OutboundSigningAlgorithm, WantAssertionsSigned, AuthenticateRequestSigningBehavior, IdpInitiatedCallbackUrl, MaxRelayStateLength and ServiceCertificates, and nothing else.

So everything chain works end to end and simply never receives a value. My local patch just null-coalesced a default into CreateAuthenticateRequest to confirm the rest of the path was fine. The real fix is a property on SamlProvider or SamlAuthenticationOptions, mapped through SamlConfigureOptions.

One request: please expose it on the provider options rather than as a global setting. SPOptions is already per-provider in the dynamic provider model, so mapping it in SamlConfigureOptions gives per-federation configuration for free. We onboard partners across different IdPs and they won't agree on a single Name ID format, so a global option wouldn't work for us.

[jwalker-hw]

@wcabus - any movement on this? Trying to decide whether we're shipping our first version without signing SAML responses. ( It's ok if we do ) . But I was waiting just in case a new patch was available shortly.

[wcabus]

While the fix on our end should be straightforward, there may be other quirks with different SAML implementations out there, and we've been looking into them. I don't yet have an ETA, but I expect we want to release a fix addressing multiple behaviors we discovered with various providers out there.

[jwalker-hw]

While the fix on our end should be straightforward, there may be other quirks with different SAML implementations out there, and we've been looking into them. I don't yet have an ETA, but I expect we want to release a fix addressing multiple behaviors we discovered with various providers out there.

Works for me. Thanks