Shibboleth Developers

["Mark Wilcox" <>]

Only one part of J2EE deals with Sessions and that's the Servlet
specification. Normally if you use the HTTPSession object, the Servlet
container (ie Tomcat, Resin or something bigger like Weblogic, but not JBoss
or JONAS, the latter deal only with J2EE components outside of Servlet/JSPs)
handles managing that data including the sharing of the data in a cluster.
However, I think we're probably going to have to manage some of our state
ourselves given that we want Shib to be able to live in other environments
like Web Services.

I think what we should be aiming more for is the JAAS specification. JAAS is
the Java specification that deals specifically with Authentication and
Authorization. It's designed to be fairly generic (in many ways it resembles
PAM) and provides a method called "login" that you override to do your
authentication step. 

The basic premise is that you override the login method (provided by JAAS),
if it's in the Web container, it should have access to the HTTP Request and
Response objects so that you can data incoming (ie SAML ticket or SAML
response) and outgoing (ie redirect user to Origin). Tomcat includes sample
JAAS modules and WebCT Vista uses JAAS as the base API for our new SSO SDK.
I'm not plugging JAAS just for Vista, we went towards JAAS because it's the
preferred API for Java.

Mark  



-----Original Message-----
From: RL 'Bob' Morgan 
[mailto:]
 
Sent: Monday, November 03, 2003 1:16 PM
To: Scott Cantor
Cc: Shibboleth Dev Team
Subject: RE: Java and general target stuff


> 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"