[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [saml-dev] Re: Metadata, IdP Disco, AuthnRequest, etc...
Hello -- On 11 May 2007, at 16:56, Scott Cantor wrote: >> The service will redirect back to the SP, which will allow the SP to >> redirect to other IdP disco services, but what does the user >> interface look like for that? > > Up to the SP. I haven't decided what the Shibboleth SP will do yet, > and we > were the ones who proposed this thing, so to the extent that I may > be the > only one who's even thought much about it, there's not much of an > answer. I > was very up front with people that I did *not* think the DS > proposal allowed > for multiple federation SPs. I was very clear on that. Agreed, and I think multi-federation SPs will be common enough that the limitations of the current IdP disco will be felt. Maybe I'm wrong there -- what has your experience been? >> Will the first IdP disco service have a "none of these, sorry!" >> button? >> Will the user be presented with potentially three or four different > "choose >> one of these completely irrelevant choices" pages before getting >> to one > that >> has the correct choice? > > I've been clear from day one (well, ok, maybe day 400 or so ;-) > that AFAIC, > the SP MUST handle discovery and that seamless SSO even on first > contact > could not and would never work without client code. > > People want to push back on that, and the DS proposal is part of > that, but I > don't think it helps that much. I agree that for best general experience, the SP should handle IdP selection, but in the absence of a workable "global cookie" solution, I'm not sure how annoying that would be (ie, to select your IdP at each SP you visit, though I suppose an initial passive probe would solve that problem for sites after the first one; you run the risk of having to do umpteen bazillion redirects, though). The best thing would be to use some bit of browser (or other client, in the non-web world) plugin to determine, and fall back to SP- implemented asking, but that would be... difficult at the least to get people to buy in on, unless the browser (and other client) producers also buy in. > But to answer you, I considered the multiple DS case more of an > option with > the isPassive flag, because you wouldn't have the UI to worry > about. That > doesn't get the cookie set in the first place, though, so I guess > the vague > notion was that a passive probe might get you something, and if > not, you > could have the SP offer a first choice of branded options to select > from to > get to the right DS. That's a very questionable and unproven idea. Getting people to remember what an Onyen (or NetID, or whatever an institution calls it) is is hard enough. Making them remember that if they're at site X to choose federation Y, but at Z choose W is not really feasible. I think, anyway. KH -- Karsten Huneycutt Systems Specialist, ITS Identity Management kph@unc.edu
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]