Shibboleth Developers

[Ian Young <>]

Scott Cantor wrote:

> > Well, in our case SP descriptions are created while being authenticated
> > with SWITCHaai. After creation by an SP admin, the SP description has to
> > be approved by an Resource Registration Authority admin (RRA) of the
> > organization that this SP description is registered for. The RRA then
> > has to check the assertion consumer URLs, required attributes etc. and
> > the embedded certificate(s).
>
> That authentication process is what dictates your security, not PoP. I think
> that's what Ian's trying to point out.

Yes, exactly.

> > Now some colleagues argue like this: If you want to embed certificates
> > in the metadata, how do you make sure that the (potentially self-signed)
> > certificate that is approved by the RRA was really added to the
> > description by the legitimate SP admin and not somebody who stole the
> > person's account information?
>
> The same threat exists whether you embed the certificate or not. If I can
> get into your account, I can create a bogus SP definition, key or no key.
> The key is not sufficient for defining an SP, only the metadata as a whole
> is. The key is just one of the fields. If I were going to attack you,
> wouldn't I create the SP definition such that the callback for the metadata
> later would succeed?

This pretty much parallels the reasoning we went through: the knee-jerk 
reaction is to do PoP because people do PoP in other contexts, but 
what's really important is that *all metadata has to be authenticated as 
coming from the owner of the entity*.

Everything is only as strong as your authentication of the source of the 
metadata (not just keys, but everything else too).  If you don't do that 
well, you have a hole so large that PoP checking won't plug it.  If you 
do it well, you don't need PoP at all (as far as we can see).

        -- Ian