Enforce NOT Encrypting the Assertion?


Is it possible to enforce the assertion to NOT be encrypted? Setting WantAssertionEncrypted to FALSE doesn’t do it.

If not, then is it possible to determine programmatically if the received assertion is encrypted?
We use the automatic handling of the assertion:
var ssoResult = await _samlServiceProvider.ReceiveSsoAsync();
and the result doesn’t seem to carry any such information.

Thank you!

It isn’t possible to enforce the assertion not to be encrypted.

You could detect whether the SAML assertion is encrypted by receiving the OnSamlResponseReceived event and seeing whether the SAML response contains a SamlAssertion or EncryptedAssertion.

May I ask why you want to do this?

Normally whether or not the SAML assertion is encrypted is something that’s agreed to between the service provider and partner identity provider.

Thank you for the prompt response!

The problem I’m trying to solve: we want to know which of our IdP partners use our certificate for sure, so when the time comes to renew it, we don’t bother the clients that don’t use it (which is the majority).
(Because most of them - if they reply at all - get confused by our emails, are not sure what we are talking about, have had IT contacts change, etc. and it’s just a time waste for all.)

Most times clients do mention they want the assertion encrypted, but just today we had SSO break for a client who did not reply to our message regarding certificate renewal, and had not mentioned they are encrypting the assertion when we were setting up the SSO (or maybe they started doing that later?). We’d like to catch cases like these before certificate renewal time.

I’d appreciate any other ideas you may have!

Your certificate is used for signing SAML messages you send as well as encrypting the SAML assertion you receive.

You can tell from the PartnerIdentityProviderConfiguration whether or not you’re signing SAML messages sent to them (eg SignAuthnRequest etc).

You can also tell whether you want the SAML assertions encrypted (ie WantAssertionEncrypted).

However, there isn’t an easy way to tell that the identity provider will encrypt the SAML assertion regardless.

My recommendation, if possible, is to ask those identity providers for whom WantAssertionEncrypted is false to not encrypt the SAML assertion. If it’s their requirement that they encrypt the SAML assertion then set WantAssertionEncrypted to true to match this requirement.

You can then say any identity provider with Sign* or WantAssertionEncrypted true should be given the new certificate.

You might also like to take a look at the “Certificate Rollover” section of the Certificate Guide.


It outlines some strategies for staggered certificate rollovers etc. You can also configure multiple certificates. This will help if an identity provider is still using your old certificate for the SAML assertion encryption.

Yep, all that is true…
The problem we face with some clients is they don’t quite know what “encrypting the assertion” is… And even if we discuss all this at SSO setup, someone who doesn’t know of our discussions could make the change… Relying on people for things like this is bound to fail sooner or later :slight_smile:

Hmmm now I think our best bet would be using the OnSamlResponseReceived event to detect unexpected encrypted assertions and just set WantAssertionEncrypted to TRUE for these clients. I hope this will work (without a noticeable overhead).

We are also thinking of implementing secondary certificates for assertion decryption (for signature verification most clients support a secondary cert on their end). The guide doesn’t mention this but I think I’ve seen it elsewhere in the forum, and I imagine it will work like this:
LocalServiceProviderConfiguration = new LocalServiceProviderConfiguration()
LocalCertificates = new List()
new Certificate() // Used for signature and decryption
SubjectName = “old cert here”
new Certificate() // Used for decryption if the above fails
SubjectName = “new cert here”


We can have this for, say, 2 weeks, then swap the “old” and “new” cert entries, and after 2 more weeks remove the “old” one.
(I wouldn’t like to manage local certs for each client though.)

There’s minimal overhead in the firing of the OnSamlResponseReceived event.

When multiple local certificates are configured for the local service provider, the first certificate is always used for signing SAML messages. For decrypting SAML assertions, each certificate is tried in order until either the decryption is successful or we run out of certificates to try.

Handling the OnSamlResponseReceived event and setting WantAssertionEncrypted to TRUE for clients with encrypted assertions seems to be working well (in our testing environment)!
Configuring multiple local certificates will be our next step.

Thank you for your assistance!

You’re welcome. Let me know if you have any other questions.