Skip to Content.
Sympa Menu

shibboleth-dev - RE: Discovery Service

Subject: Shibboleth Developers

List archive

RE: Discovery Service


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: <>
  • Subject: RE: Discovery Service
  • Date: Mon, 30 Oct 2006 13:20:28 -0500
  • Organization: The Ohio State University

Closing the loop on some identified questions or concerns...

> > > Also, since the return URL is arbitrary, how do you prevent a
> > > rogue SP from spoofing the user to divulge their preferred IdP?

Discussed this on the call. It was felt that while this is a threat, the
ability to phish today is not significantly aided by this proposal. Having a
packaged WAYF with public metadata (that's a key factor, but many feds do
publish theirs openly) makes it very easy for a rogue SP to deploy their own
discovery site.

Preventing this leak would require a wholesale registration of SP discovery
return points (i.e. probably SessionInitiators) so that the WAYF could
prevent leaks. This would be even more proprietary extension, and
effectively precludes the kinds of bilateral arrangements possible now
between sites, which may look attractive to federations seeking to
artifically provide value, but I see it as a step backward.

If people think this is a real threat, they should speak now. We can only
say that phishing is a problem, and IdPs probably do need to start hardening
themselves.

Also, federations could build a WAYF plugin that did some kind of return
checking if they wanted to, assuming they're prepared to collect the
information and disallow SPs outside the federation formally from using the
WAYF. The decision isn't meant to preclude it, just not meant to require it.

> > > To integrate with the SessionInitiator at the SP, would it be better
> > > to call the output parameter 'providerId' instead of 'entityID'?

There are caveats to the ability to feed a 1.3 SP with the right information
(namely what happens when you omit the target parameter), but for this an
other reasons, the original proposal in DC was to permit the name of the
return parameter to be SP-specified. We lost this in Memphis, but we've
added it back.

I think people will find we need to patch 1.3 to get a better experience,
which is why it wasn't the focus, but if we can make it work in some cases,
we will.

-- Scott




Archive powered by MHonArc 2.6.16.

Top of Page