ComponentSpace

Forums



Enforce NOT Encrypting the Assertion?


Enforce NOT Encrypting the Assertion?

Author
Message
AnnaK2022
AnnaK2022
New Member
New Member (6 reputation)New Member (6 reputation)New Member (6 reputation)New Member (6 reputation)New Member (6 reputation)New Member (6 reputation)New Member (6 reputation)New Member (6 reputation)New Member (6 reputation)

Group: Forum Members
Posts: 4, Visits: 59
Hello,

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!
ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)

Group: Administrators
Posts: 3.2K, Visits: 11K
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.




Regards
ComponentSpace Development
AnnaK2022
AnnaK2022
New Member
New Member (6 reputation)New Member (6 reputation)New Member (6 reputation)New Member (6 reputation)New Member (6 reputation)New Member (6 reputation)New Member (6 reputation)New Member (6 reputation)New Member (6 reputation)

Group: Forum Members
Posts: 4, Visits: 59
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!


ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)

Group: Administrators
Posts: 3.2K, Visits: 11K
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.

https://www.componentspace.com/forums/8238/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.


Regards
ComponentSpace Development
AnnaK2022
AnnaK2022
New Member
New Member (6 reputation)New Member (6 reputation)New Member (6 reputation)New Member (6 reputation)New Member (6 reputation)New Member (6 reputation)New Member (6 reputation)New Member (6 reputation)New Member (6 reputation)

Group: Forum Members
Posts: 4, Visits: 59
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 :)

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<Certificate>()
{
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.)

ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)

Group: Administrators
Posts: 3.2K, Visits: 11K
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.



Regards
ComponentSpace Development
AnnaK2022
AnnaK2022
New Member
New Member (6 reputation)New Member (6 reputation)New Member (6 reputation)New Member (6 reputation)New Member (6 reputation)New Member (6 reputation)New Member (6 reputation)New Member (6 reputation)New Member (6 reputation)

Group: Forum Members
Posts: 4, Visits: 59
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!


ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)

Group: Administrators
Posts: 3.2K, Visits: 11K
You're welcome. Let me know if you have any other questions.

Regards
ComponentSpace Development
GO


Similar Topics


Execution: 0.000. 2 queries. Compression Enabled.
Login
Existing Account
Email Address:


Password:


Select a Forum....












Forums, Documentation & Knowledge Base - ComponentSpace


Search