shibboleth-dev - RE: shireURL, providerId, applicationId, and target parameters
Subject: Shibboleth Developers
List archive
- From: "Scott Cantor" <>
- To: "'Howard Gilbert'" <>, <>
- Subject: RE: shireURL, providerId, applicationId, and target parameters
- Date: Fri, 5 Nov 2004 14:21:54 -0500
- Organization: The Ohio State University
> 2) The SHIRE is in the /shibboleth context. It gets the post and then
> hands a session identification off to the Resource Manager with a
> generated Session ID UUID appended to the URL and then stripped by the
> Filter. In this case there are two session cookies, one from the
> /shibboleth context and one from the Resource context.
Understood, thanks. I guess I'd say that my discomfort with it mostly arises
from a fear of appending anything to application URLs. It's the reason I
didn't build my own WebISO in a manner that exchanged data on application
URLs.
I may be (and probably am) wrong to think that this was unworkable, but I
had dismissed it originally.
Actually there is another reason...I don't like exposing the session ID on
the URL at all. It leads to session IDs showing up in logs. But that's
solvable if the value on the URL is only a one-time token that maps to the
real value. As long as the filter and the POST handler can share data, this
works.
So, I can see that this has the benefit of avoiding the need for multiple
URLs in metadata just to support additional vhosts or applications, but I
think that your scenario about the math professor is questionable, IMHO. If
he's putting a new application up, he probably needs a new providerId
because his application's data requirements might be different from somebody
else's.
Plus, transiting a session (and data) from a single Shib cookie to a new
cookie for that app really just circumvents one entire reason for vhosting
to begin with, to keep them separate.
I guess what I'm saying is that the act of registering the endpoint in
metadata is like a public acknowledgement of what you're doing. If you tie
the new endpoint back to an existing SP, then you're being up front about
what you're gonna do. This is a good thing, IMHO.
We all know you can play games behind the scenes (you already can, of
course, just play your own cookie tricks in the application space), but this
sort of "legitimizes" it architecturally in a way that I'm a little
concerned by. Maybe I'm making too much of the distinction?
-- Scott
- shireURL, providerId, applicationId, and target parameters, Howard Gilbert, 11/05/2004
- speaking of the java class, Mark Wilcox, 11/05/2004
- Re: speaking of the java class, Walter Hoehn, 11/05/2004
- RE: speaking of the java class, Mark Wilcox, 11/05/2004
- Re: speaking of the java class, Walter Hoehn, 11/05/2004
- Re: shireURL, providerId, applicationId, and target parameters, Tom Scavo, 11/05/2004
- RE: shireURL, providerId, applicationId, and target parameters, Mark Wilcox, 11/05/2004
- RE: shireURL, providerId, applicationId, and target parameters, Scott Cantor, 11/05/2004
- RE: shireURL, providerId, applicationId, and target parameters, Howard Gilbert, 11/05/2004
- RE: shireURL, providerId, applicationId, and target parameters, Scott Cantor, 11/05/2004
- RE: shireURL, providerId, applicationId, and target parameters, Howard Gilbert, 11/05/2004
- speaking of the java class, Mark Wilcox, 11/05/2004
Archive powered by MHonArc 2.6.16.