<div dir="ltr"><div dir="ltr"><div dir="ltr" class="gmail_attr">On Thu, Jul 30, 2020 at 8:33 AM Cantor, Scott <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>
<br></blockquote></div><div dir="ltr"><br></div><div>Thanks Scott, adding an encryption method to the SP metadata for AES128-CBC did the trick:</div><div><br></div><div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><EncryptionMethod Algorithm="<a href="http://www.w3.org/2001/04/xmlenc#aes128-cbc">http://www.w3.org/2001/04/xmlenc#aes128-cbc</a>" /><br></div></blockquote></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">On Thu, Jul 30, 2020 at 8:37 AM Peter Schober <<a href="mailto:peter.schober@univie.ac.at">peter.schober@univie.ac.at</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">* Raymond DeCampo <<a href="mailto:ray@decampo.org" target="_blank">ray@decampo.org</a>> [2020-07-30 14:25]:<br>
> I also have mod_auth_mellon on Apache httpd on another server which I would<br>
> like to use as the SP.  I have verified that it works with <a href="http://samltest.id" rel="noreferrer" target="_blank">samltest.id</a> as<br>
> the IdP either with a both encryption and signing <KeyDescriptor> elements<br>
> or only with a signing <KeyDescriptor>.<br>
> <br>
> When I configure my SP to use my local Shibboleth installation as the IdP,<br>
> it will work successfully if I only have the signing key.  But it does not<br>
> work if I include the encryption key.<br>
<br>
That doesn't match the IDP's default behaviour: The IDP will terminate<br>
with an error for an SP that doesn't have an encrypted key listed.<br>
Did you create an override for this SP specifically or did you change<br>
that default behaviour globally?<br></blockquote><div><br></div><div>Yes, I changed the shibboleth configuration to make encryption optional.  I suppose I can change it back now.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> When using the encryption key in my SP metadata, it appears to login<br>
> successfully but when redirected back to the AssertionConsumerService URL,<br>
> I get a 400 Bad Request response from the SP with the following message in<br>
> the logs:<br>
> <br>
> [Thu Jul 30 07:04:45.374462 2020] [auth_mellon:error] [pid 29013] [client<br>
> <a href="http://10.0.2.2:60010" rel="noreferrer" target="_blank">10.0.2.2:60010</a>] Error processing authn response. Lasso error: [-427] When<br>
> looking for an assertion we did not found it<br>
<br>
Then you probably gave the IDP the wrong metadat (or key within that<br>
metadata). Since most SPs don't sign their authn request by default<br>
no signing key of that SP was ever used.<br>
<br>
> The SP metadata:<br>
<br>
Personally I'd simply list the key once without a use-restriction,<br>
instead of listing it twice with both uses allowed. mod_mellon<br>
supports encryption so there's no need to hand-craft metadata without<br>
an encryption key for it.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
BUt we can't tell you whether that matches your deployment.<br>
There's no magic involved: give the IDP metadata with the a<br>
certificate and the IDP will encrypt the SAML with that certificate.<br>
If that certificate matches what the SP expects then It Should Work™.<br>
<br>
> The Shibboleth IdP metadata is the sample which comes with the<br>
> install, updated for the expiration date and adding the port to the<br>
> URLs.<br>
<br>
The IDP doesn't use that file and noone else should, either.<br>
For a toy/test deployment that doesn't matter, though. Otherwise I'd<br>
have suggested to fix the deployment instead of adding ports to<br>
protocol endpoints.</blockquote><div><br></div><div>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.</div><div><br></div><div>I am new to SAML and I would like to understand why you say no-one should use the sample IdP metadata from Shibboleth?</div><div><br></div><div>Thanks again to everyone who took the time to help.</div><div><br></div><div> </div></div></div>