Encryption works against samltest.id but not local Shibboleth IdP

[Peter Schober]

* Raymond DeCampo <ray at decampo.org> [2020-07-30 14:25]:
> I also have mod_auth_mellon on Apache httpd on another server which I would
> like to use as the SP.  I have verified that it works with samltest.id as
> the IdP either with a both encryption and signing <KeyDescriptor> elements
> or only with a signing <KeyDescriptor>.
> 
> When I configure my SP to use my local Shibboleth installation as the IdP,
> it will work successfully if I only have the signing key.  But it does not
> work if I include the encryption key.

That doesn't match the IDP's default behaviour: The IDP will terminate
with an error for an SP that doesn't have an encrypted key listed.
Did you create an override for this SP specifically or did you change
that default behaviour globally?

> When using the encryption key in my SP metadata, it appears to login
> successfully but when redirected back to the AssertionConsumerService URL,
> I get a 400 Bad Request response from the SP with the following message in
> the logs:
> 
> [Thu Jul 30 07:04:45.374462 2020] [auth_mellon:error] [pid 29013] [client
> 10.0.2.2:60010] Error processing authn response. Lasso error: [-427] When
> looking for an assertion we did not found it

Then you probably gave the IDP the wrong metadat (or key within that
metadata). Since most SPs don't sign their authn request by default
no signing key of that SP was ever used.

> The SP metadata:

Personally I'd simply list the key once without a use-restriction,
instead of listing it twice with both uses allowed. mod_mellon
supports encryption so there's no need to hand-craft metadata without
an encryption key for it.

BUt we can't tell you whether that matches your deployment.
There's no magic involved: give the IDP metadata with the a
certificate and the IDP will encrypt the SAML with that certificate.
If that certificate matches what the SP expects then It Should Work™.

> The Shibboleth IdP metadata is the sample which comes with the
> install, updated for the expiration date and adding the port to the
> URLs.

The IDP doesn't use that file and noone else should, either.
For a toy/test deployment that doesn't matter, though. Otherwise I'd
have suggested to fix the deployment instead of adding ports to
protocol endpoints.

-peter