Shibboleth Developers

["Scott Cantor" <>]

> What was the thinking behind the discovery service? other than a beefed up
> WAYF, with more metadata to manage?

I explained at length last year that my design for a multi-protocol SP (I
don't build gateways) requires that the SP be the actual request issuer, not
the WAYF. That means the flow has to be SP->WAYF->SP, which is what this
protocol does. It also divorces it from the complexity of authentication
requests, which are extremely rich now.

We could have done this the way other products do, privately, and locked
everybody else out, but obviously people wouldn't have appreciated that very
much. Not only am I publishing this, I'm doing the extra work to make it an
OASIS standard.

The additional endpoint in the metadata is a phishing issue. I tried to
avoid it, but I see no way around that. It might make sense to have an
option for those running it closely associated with specific SPs to just
hardcode some of the checking instead of requiring metadata, but I'm not
sure there's any difference, it's the same information.

Always keep in mind...I think this is completely unnecessary. I think all
SPs should run their own discovery UI, and the simplest one is probably the
one that OpenID forces on its sites...you just enter your IdP. I would urge
people to consider that instead of this approach.

But that's not what people seem to want, so I'm giving them what they asked
for.

> I can see how metadata can cut that down, using the SP's entityID but it
> means even more metadata for a federation to manage.

I'm not sure what you mean by more metadata. This has no particular
implications for the volume of Shibboleth metadata apart from the extension,
and that's just one more defaulted endpoint in the software.

As far as filtering is concerned, I think in practice that's not likely to
be metadata-driven. Rod's code supports it, but so far I haven't been able
to see how it would work in most cases.

> Do you think the discovery service should use the same metadata file that
> drives the federation? So it would be one discovery service per
federation.

Nobody seems to want to stop doing this, but no, I don't see this proposal
as "fixing" anything like that. The centralized WAYF concept is still broken
and can't be fixed.

The most that this does is allow for silent redirection through many of them
at once using isPassive, without having to maintain many common domains.
Once you get back nothing from that process, you're just as stuck as you are
now.

> > There was particular concern about products not working
> > with Shib sites if we do this
>
> How do you define "product"?

Other SAML 2.0 implementations, particularly the ones we get asked about,
which are mainly commercial and wouldn't be as likely to widely implement
this if it wasn't published at OASIS.

> > multi-protocol sites, which of course all the products have to handle.
>
> can you explain what you mean by this?

SAML products all support SAML 1.x and SAML 2.0, and usually ADFS to boot.
In the future that may also include Cardspace. That's 4 protocols and
probably 12+ bindings to handle at once, most all of them based on knowing
who the IdP is before you can issue a request properly (Cardspace is the
exception of course).

> I've seen a lot of talk of IP address matching at WAYFs. Is this a viable
> addition to the discovery service? i.e. if you're on campus, the discovery
> service can be passive if the sp knows your IP address. i.e. SP tries a
> passive query to the service and if nothing comes back it says to the user
> "no idea, go find it yourself".

As Ian said, the SP has nothing to do with this. The DS is talking with the
user, it has the same address the SP does. (Ignoring NAT, but NAT breaks a
lot of things.)

This is not a protocol between the SP and the DS alone. The browser is still
in the middle.

> Once past the initial metadata check, the more the sp can give the service
> to allow it to make a passive decision the better?

Yes, and that also makes the whole thing more complex. There is a balance
here.

> I can see semantic type decisions coming into play. i.e. SP tells the
> service "I'm a medical records service and someone from uhi.ac.uk is
> trying to access me. Where is their IdP likely to be?". A semantic
> discovery service? It could drastically reduce the likely list of IdPs
> from thousands to a handful. Given enough data it could match it. But the
> metadata doesn't support that just now. Maybe it should in future.

And I think people should just stop trying to offload discovery and do it in
the application where the decision can be made with the most information.

-- Scott