shibboleth-dev - RE: Continuing the cookie discussion...
Subject: Shibboleth Developers
List archive
- From: "Scott Cantor" <>
- To: "'Howard Gilbert'" <>, <>
- Subject: RE: Continuing the cookie discussion...
- Date: Sat, 18 Dec 2004 18:38:37 -0500
- Organization: The Ohio State University
> The target= value becomes a one time use externally meaningless token. We
> need some token because, having been redirected to the WAYF, a user may
> abandon an attempt to access this resource and turn his attention to a
> different resource, even a different URL under the control of the same RM.
> The target isn't a security token, just a routing slip. By saving and
> restoring the original URL on the final redirect, nothing is added or
> changed that could adversely effect the application.
I understand the idea, I just think we have to be careful with it and make
sure there's no hole being opened up by attaching state to something that is
making a trip between the SP and IdP. This is what RelayState (or TARGET) is
for, but it has to be carefully used, since somebody else can attach a
stolen value to their own valid SAML assertion/response.
My question was whether anything can be gained by doing this. Perhaps not, I
just want to be sure.
> OK, but I need the HttpSession to be part of the API to the application.
> So the trick here will be to compare the Cookie (which now can't
> be predicted) to the ID in the HttpSession block that the Application
> Server assigns to the request. We require that the two match.
Right. This is how I do it with the older non-Java Cold Fusion, which also
has an insecure session ID mechanism. It's even been known to issue the same
session ID to two clients at the same time. That's when I learned to be
paranoid about it and assume all app servers were written by lunatics.
> pass on to the application. There can be other sanity checks
> (IP address?)
Right, that's a check that also ought to continue to be supported, and I
don't know whether Java's mechanism does this for you (I know CF's didn't).
Again, better to assume nothing since it's so easy to fix.
> Does this meet everyone's expectations?
It meets mine. Since I'd like to alter the way 1.3 uses the target parameter
in the old implementation as well, I'll have to consider whether dropping
the cookie first has any advantage for me.
-- Scott
- Continuing the cookie discussion..., Scott Cantor, 12/13/2004
- RE: Continuing the cookie discussion..., Howard Gilbert, 12/13/2004
- RE: Continuing the cookie discussion..., Scott Cantor, 12/13/2004
- Re: Continuing the cookie discussion..., Walter Hoehn, 12/15/2004
- RE: Continuing the cookie discussion..., Howard Gilbert, 12/16/2004
- Re: Continuing the cookie discussion..., Tom Scavo, 12/17/2004
- RE: Continuing the cookie discussion..., Howard Gilbert, 12/18/2004
- RE: Continuing the cookie discussion..., Jim Fox, 12/18/2004
- RE: Continuing the cookie discussion..., Scott Cantor, 12/18/2004
- RE: Continuing the cookie discussion..., Howard Gilbert, 12/18/2004
- RE: Continuing the cookie discussion..., Scott Cantor, 12/18/2004
- Re: Continuing the cookie discussion..., Tom Scavo, 12/19/2004
- RE: Continuing the cookie discussion..., Scott Cantor, 12/19/2004
- Re: Continuing the cookie discussion..., Tom Scavo, 12/19/2004
- RE: Continuing the cookie discussion..., Scott Cantor, 12/19/2004
- RE: Continuing the cookie discussion..., Howard Gilbert, 12/18/2004
- RE: Continuing the cookie discussion..., Howard Gilbert, 12/19/2004
- RE: Continuing the cookie discussion..., Scott Cantor, 12/19/2004
- RE: Continuing the cookie discussion..., Howard Gilbert, 12/19/2004
- RE: Continuing the cookie discussion..., Scott Cantor, 12/19/2004
- Re: Continuing the cookie discussion..., Tom Scavo, 12/17/2004
- RE: Continuing the cookie discussion..., Howard Gilbert, 12/16/2004
- Re: Continuing the cookie discussion..., Walter Hoehn, 12/20/2004
- RE: Continuing the cookie discussion..., Howard Gilbert, 12/21/2004
- RE: Continuing the cookie discussion..., Howard Gilbert, 12/13/2004
Archive powered by MHonArc 2.6.16.