IdP assertions encryption issue

[Guillaume Rousse]

Hello list.

In order to prepare a migration of some services from one reverse-proxy 
to another, we published yesterday the new SP certificate in our 
metatada, alongside the current certificate. This morning, this resulted 
in access failure for those services, with this error message:
failure to retrieve authentication statement for the SP:
opensaml::FatalProfileException at (http://....)
A valid authentication statement was not found in the incoming message.

We fixed the issue by deploying the new certificate on the current 
reverse-proxy, so as to have the setup matching the metadata.

Searching shibboleth documentation, this seems to be an encryption 
issue, corresponding to the problem described hre:
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPMultipleCredentials

Basically, when the same certificate/key pair is used both for 
encryption and signature, you can't satisfy both migration constraints 
at once (publishing before using for signature, using before publishing 
for encryption). Before as soon as a new certificate is available for 
encryption, IdP may start using it, and if the SP doesn't actually use 
it, it will fails to decrypt received messages.

However, I don't understand why, given its current configuration, our 
IdP does encrypt its assertions. That's an old version (2.4.4), but all 
the profile defined in relying-party.xml have encryptAssertions 
attribute set to "never" or "conditional". It's a bit difficult to 
understand what this setting does exactly, given than IdP 2.x 
documentation seems to have been removed from Shibboleth consortium 
wiki, but the IdP 3.x documentation gives an hint here:
https://wiki.shibboleth.net/confluence/display/IDP30/SecurityConfiguration#SecurityConfiguration-SigningandEncryptionEnablement

"Most commonly this would be used in conjunction with a built-in 
condition that works by deciding whether to sign or encrypt based on the 
security of the underlying communication channel. It is equivalent to 
the V2 setting of "conditional" in the legacy configuration format."

According to my understanding, given than our services use https only 
(all http connections are automatically redirected to https), encryption 
should never happen.

I'm obviously wrong somewhere, but I can't figure where exactly :(
-- 
Guillaume Rousse
Pôle SSI

Tel: +33 1 53 94 20 45
www.renater.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3637 bytes
Desc: Signature cryptographique S/MIME
URL: <http://shibboleth.net/pipermail/users/attachments/20180131/7fcbfc35/attachment.p7s>