Encryption works against samltest.id but not local Shibboleth IdP

[Raymond DeCampo]

On Thu, Jul 30, 2020 at 8:33 AM Cantor, Scott <cantor.2 at osu.edu> wrote:

> Most likely mod_mellon doesn't support AES-GCM, only AES-CBC. This is
> covered extensively in the wiki via the Release Notes regarding the
> encryption changes in 4.0.
>
>
Thanks Scott, adding an encryption method to the SP metadata for AES128-CBC
did the trick:

<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc" />



On Thu, Jul 30, 2020 at 8:37 AM Peter Schober <peter.schober at univie.ac.at>
wrote:

> * 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?
>

Yes, I changed the shibboleth configuration to make encryption optional.  I
suppose I can change it back now.


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

Thanks, I will try removing the use attribute.  BTW, the metadata without
the encryption configuration was generated using the script provided by
mod_auth_mellon.


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


Yes, I am aware the IdP doesn't use that file.  I want my deployment
running on 8443 which is why I changed the URLs.  I have other services
running on that server on 443 and I'm not keen on trying to get everything
to kumbaya together on the same port.

I am new to SAML and I would like to understand why you say no-one should
use the sample IdP metadata from Shibboleth?

Thanks again to everyone who took the time to help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20200730/096b2fd0/attachment.htm>