Encryption works against samltest.id but not local Shibboleth IdP
ray at decampo.org
Thu Jul 30 13:46:15 UTC 2020
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>
> * 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
> > like to use as the SP. I have verified that it works with samltest.id
> > the IdP either with a both encryption and signing <KeyDescriptor>
> > or only with a signing <KeyDescriptor>.
> > When I configure my SP to use my local Shibboleth installation as the
> > it will work successfully if I only have the signing key. But it does
> > 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
> > I get a 400 Bad Request response from the SP with the following message
> > 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]
> > 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
> 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...
More information about the users