Session != Login

[Charles Forsythe <fo...@netvoice.net>]

Andy Nuss wrote:
> So assuming the site requires "single sign-on".  And that there are
> several segmentations of the site, each of which could
> be handled by a different web-app:
> 
> I'm getting the impression that I'm supposed to do some
> kind of magic with the session cookie.

Sessions do not have anything to do with sign-on, single or otherwise. 

Think of a Session ID as a tag you place on a wild animal so that you
can track its movement amongst a zillion other identical-looking
critters.  (This animal is a browser, and the tag is usually a browser
cookie).

The HttpSession object just represents a uniquely-tagged browser.  You
can attach properties to the Session object and they will follow the
movements of the client within the scope of the web application.  One
attribute MIGHT be the authentication status of the client.

I say MIGHT because there are a lot of ways to do authentication and
attaching a property to the Session is only one of them.  You may end up
doing something completely different if your application calls for it. 
Your example of single-signon is perfect.  You may have to set an
cross-application cookie as a tag to allow application state to follow
the client across applications.  In some cases, that won't work either
(an example is single-signon across foo.com and bar.com) and you'll need
to do something different, maybe involving multiple cookies, maybe not
using cookies at all.

> What's the rationale behind this architecture?

There is no architecture.  There are tools which you can use to *create*
an architecture.  Sessions, Cookies, HTTP authentication and (soon)
Filters are just peices available for you to put together to provide an
authentication and authorization model that serves your needs.

The Filter capabilties in Servlet 2.3 (Tomcat 4.0) will make the
addition of sophisticated authentication schemes extremely modular and
straightforward.

-- Charles
P.S. And JUST SAY NO to container-managed security.