Re: Introducing a Session header...

The SSO is something we negotiate between two or more origin servers, and
the UAs need not be part of that negotiation. It's may be the
simpler design step to use the UAs for such negotiation between servers
(with such "session header") after we establish the connection, yet that
does not help secure authentication.

The hint for redirection is correct, the origin server(s) may create new
resource, upon UA connection,  and encode any session/state in that
resource without affect to the headers.

On Friday, July 20, 2012, Willy Tarreau wrote:

> On Fri, Jul 20, 2012 at 01:45:50PM +0100, Ross Nicoll wrote:
> > On 20/07/2012 13:35, Poul-Henning Kamp wrote:
> > >In message <8d6b6668433e8aa7c67601ab9b0f485d.squirrel@arekh.dyndns.org<javascript:;>
> >,
> > >"Nicol
> > >as Mailhot" writes:
> > >
> > >>The problem if you do it this way is that:
> > >>3. the user agent has no information if it should share the id with
> > >>another site or not
> > >Ohh, that's the disconnect:  It should _never_ share the session-id
> > >with any other site, that's sort of the entire point.
> > We rather do want sites to share session IDs, actually, so we can do
> > easy single-sign-on. At the moment we fairly much only do this within a
> > domain, but in the future we might see something like Project Moonshot (
> > http://www.project-moonshot.org/ ) providing single-sign-on for all UK
> > academic institutions (this is really useful for cases such as external
> > examiners being able to access resources in institutions not their own,
> > for example). Of course, we do also want to control how session IDs are
> > shared (I don't think it's something I'd want my bank doing!)
>
> Note that SSO actually does work cross-domain using redirects. It's just
> not the easiest thing to do but it does work. Cross-domain cookies are
> extremely dangerous and badly used. I regularly see some websites ask me
> for help with their site behaving in a bad way using new browsers and I
> can tell you that sometimes you see scary things. I'm glad Adam Barth has
> worked on RFC6265 to remind what's right and what's wrong.
>
> Regards,
> Willy
>
>
>