Encryption works against samltest.id but not local Shibboleth IdP

[Raymond DeCampo]

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

> * Raymond DeCampo <ray at decampo.org> [2020-07-30 15:46]:
> > I am new to SAML and I would like to understand why you say no-one
> > should use the sample IdP metadata from Shibboleth?
>
> Well, it's unsigned and even if it were signed it doesn't have a
> useful validUntil value and even if it did have one there's no process
> included out of the box to regularly push that date a few days/weeks
> into the future.
>
> As it is it's a plain text file with cryptographic keys in it.
> Are you suggesting that it's a wise practice to blindly trust
> cryptographic material downloaded automatically over thet network --
> as these keys are later used to verify protocol messages?
>

I'm not suggesting anything, I'm new at this and I'm trying to learn best
practices.

But we seem to have a misunderstanding.  When I say I was using the sample
metadata file, I did not mean I was downloading the file from the
Shibboleth server nor did I configure my SP to download the metadata.  I
mean I started with that file, made a few edits as noted and transferred
the file to my SP configuration using SFTP.

So when you said no-one should use it, I thought you meant there was
something about the contents or configuration choices of the metadata
within the file itself whereas if I understand you correctly, you were
objecting to the means of obtaining the metadata.


> Are you doing that in other contexts, e.g. automatically downloading
> (and trusting, without human intervention) a list of CA certificates?
> That's what pointing some SAML implementation to your IDP's metadata
> endpoint comes down to. Anyone able to subvert TLS to that endpoint
> would be able to introduce different key material which could
> ultimately be used to "verify" fraudulent protocol messages (i.e.,
> essentially impersonate anyone at your IDP).
>
>
That is a good reason not to download the metadata directly from the server
and I will keep that in mind.

Thanks for your help Peter.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20200730/cc8bdeae/attachment.htm>