UnverifiedRelyingParty

[Cantor, Scott]

On 8/1/17, 10:40 PM, "users on behalf of Eric Hattemer" <users-bounces at shibboleth.net on behalf of ehatteme at usc.edu> wrote:

> But do we really need metadata for SAML2.SSO, where the user is voluntarily giving their data to that SP?
> I figure the answer is "yes", and I am missing something important.

From my point of view, if we felt the trust layer didn't matter, then we wouldn't have bothered creating SAML, and would have just used existing protocols that didn't require a trust layer. It's not really for me to say or to convince people what should matter to them.

There are broken SPs that omit certain checks that become more vulnerable to attacks if IdPs operate promiscuously in some cases, but those are not common.

I will say that we didn't design the system to assume consent, and the use of consent is the main reason GMail was so vulnerable to that malicious site attack. People don't take it seriously, they just click until the thing works. If you want to punt control to the user, you're in good company. It obviously didn't hurt Google any to just blame the users.

It also depends a lot on what the consent page says. You would need to be sure that the value you presented to the user was strictly the requested response URL, because there's nothing else you could trust. I suppose you could implement a lookup table from URLs to some kind of service description, but, well, that's what metadata is.

> Related question: if the SP tries to sign its requests, is there a way
> (in IdP3) to ignore the signature?

The checks are implemented as webflows that are wired in with the inboundInterceptorFlows property (see relying-party-system.xml) and you would have to either craft one and override the proprerty or possibly just null it out, as I'm not sure it's worth much doing any checking in such a case anyway.

-- Scott