IdP assertions encryption issue

[Peter Schober]

* Guillaume Rousse <guillaume.rousse at renater.fr> [2018-01-31 17:38]:
> opensaml::FatalProfileException at (http://....)
> A valid authentication statement was not found in the incoming message.

So you published (and IDPs started using) a key the SP didn't have
configured yet.

> 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.

The SP should have any keys locally configured/available before
publishing those keys via metadata. That's why one should decoupling
the software configuration from the metadata changing/publishing.

> 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".

That's a very old question, see the archives. "conditional" basically
means "If it's not end-to-end secured -- as in: goes over the web
browser -- I'll encrypt it".

> 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

Nothing has been removed, you're mistaken. In case you were looking
for a wiki space called "IDP2"someting: that never existed, the old
documentation is still available in the "SHIB2" wiki space.

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

When pushing data over the browser TLS is terminated at the browser in
both cases: when connecting to the IDP web server, and again when
connecting to the SP webserver. Meaning HTTPS cannot secure the data
/at/ the browser, so it would be exposed to malware etc. running in
the browser or the local OS.

-peter