Shibboleth Developers

[Tom Scavo <>]

On Thu, 16 Dec 2004 00:00:31 -0500, Howard Gilbert
<>
 wrote:
> > Can't we just do some JNDI magic to allow the session data to span
> > these contexts without re-directs?
> 
> We already have magic to allow the Session object (managed by the
> /shibboleth context), to be available upon request to the Resource Managers.

Can you briefly explain how you're sharing the security context across
application contexts?

> The purpose of the cookie is not to carry the Session data, but only to
> identify the session. Only the Browser can carry a token that identifies an
> HTTP request with some existing server-side state. So again it becomes a
> problem for cookies and their scope.

Why can't the cookie be scoped to the entire server (path=/)?

> The purpose of the redirects is not to move the session data around. It is
> to redirect the Browser from a URL scope where no cookie has been assigned
> to a trusted, authoritative URL within the scope of a preexisting cookie.
> There the cookie can be read, the identity of the Browser can be
> established, and then the old Session ID can be extended to the new context
> where a new cookie can be issued for it.

I'm not sure I follow...are there now two cookies?  If the /shibboleth
context sets this second cookie as well, don't you have the same
problem?  Why not broaden the scope of the first cookie?

Seems the Resource Manager must distinguish a request that has an
associated security context from one that doesn't.  If the request
does not have a cookie, the client should be redirected to the IdP
(via the WAYF).  Otherwise the cookie is resolved into the
corresponding security context (which itself is tricky in a J2EE
environment).

Tom