RE: [saml-dev] discovery?

["Scott Cantor" <cantor.2@osu.edu>]

This is long because this is a rathole.

> Is there a profile that includes 'IpD iscovery'? By which I mean a  
> user interacts with a relying party and tells it who their IdP is. The RP 
> then talks to the IdP to see what services it provides... then the regular
> request/response occurs.

<soapbox>
Discovery is the thing that is holding back federation in general. If I get
any consistent response when I advocate for it, it's "sorry, we're not about
to add prompts to the process before the user can enter their password". The
conversation gets mostly ugly after that.
</soapbox>

Within the context of the SAML SSO profile, there is no standard way to do
discovery. There is a very limited (IMHO mostly worthless) profile that
discusses how to use a common domain cookie to store the set of IdPs used by
a user agent. The name and format of the cookie is standardized. The means
by which the cookie is maintained or read are not, because the profile is
predicated on both the IdPs and SPs maintaining an actual web presence in
the common domain. You can see how useless this is in all but
small/bilateral deployments.

There are many ways one can do discovery for web SSO, and they all suck
unless you change the client. But they all work equally (badly) in SAML as
they do in just about any other federated system. Lots of systems start with
the assumption that the user should enter something at the SP. In SAML, that
"thing" would be the IdP name/providerId (or something that can be turned
into it). Given that, you can get SAML metadata (or you might already have
it) for that IdP and you know where to send the client.

This is assuming the flow is for an unmodified browser, in which the SP has
to know not only "who" but "where". If you have more client (e.g. the SAML
Enhanced Client profile), then the SP can say "here's my request, you
deliver it".

One could also imagine a client that could at least manipulate a set of
cookies, all with a consistent name and format, across many SPs, thus
getting around the shared domain problem.

In asking your question, you're broadening the scope of "discovery" to more
than just what one considers in SAML SSO, because there, all you really need
is the SSO service endpoint. It's not about "what services".

But SAML metadata can certainly capture lots of other services, and it can
point at other metadata formats, and there are many ways of expressing that
kind of information in the world anyway, inluding some I suspect you know
already, so the answer is basically that SAML's pretty agnostic to all of
it, even if SAML products might not be. The goal for 2.0 was to *at least*
provide a basic metadata schema so that people could use something workable.

HTH,
-- Scott