[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [saml-dev] discovery?
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]