Shibboleth Developers

["RL 'Bob' Morgan" <>]

> Well, Walter and I were, I think, hoping that the J2EE session model
> would save us here, and avoid the need for both a physical session
> handle separate from that, and from any web service stuff. It occurs to
> me that maybe sessions in Tomcat are confined to a single context. I can
> see how that creates a problem for the "single SHIRE URL" model I want,
> but seems like there should be a way around that. Something simpler than
> a web service anyway. That creates a lot of nasty questions about
> securing that query.

Hmm, seems like some research is needed into how Java app servers support
load-balanced sessions.  It would be nice not to have to undertake
reinventing a segment of this wheel.

I don't see why a Web Service protocol has any different security issues
than a SAML protocol (or even that the SAML isn't a WS protocol)?

> If we absolutely *had* to remote the query right off the bat, the
> obvious choice would be to simply use SAML protocol again, with the
> local web service acting as a proxy AA forwarding the same assertion it
> got from the real AA.

This could be true if the services provided by the Shib session manager
are exactly the same as those provided by the AA, but I don't think they
are.  For example, there will want to be a "kill session" or at least
"release session" operation from app to session manager.  You could easily
convince me that this set of services is exactly the set provided by the
yet-to-be-defined SAML Session Authority, though, so if you want to start
defining that SAML protocol ... 8^)

 - RL "Bob"