tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: Sharing sessions across contexts?
Date Sat, 07 Oct 2000 02:42:32 GMT
Raimee wrote:

> Sorry for budding in Lawrence. But you have brought up a problem I am
> having and Craig has offered some interesting solutions.
> > As long as all these servlets run in a single webapp, you would not have
> > any problems using session based security.
> >
> > What you are describing is somewhat similar to the "single sign on" support
> > that was just added to Tomcat 4.0.  It relies on webapps that use the
> > container-managed security features of the servlet 2.2/2.3 APIs, and works
> > like this:  the first time the user tries to access a URI protected by a
> > security constraint, the user must log in according to the login
> > configuration of that webapp.  However, their user identity is propogated
> > across all the webapps of this virtual host so the user won't be challenged
> > to log in to each webapp individually.
> When you say the user id is propogated accross all webapps, I infer that
> it should be availible to a servlet in any context. Though, I'm not certain how
> a servlet would obtain it; if it can't be bound to a session. Now, when you say
> that
> servlets running in different contexts can be 'combined' into a single context
> -
> from the point of view of the servlet container - you've lost me. Am I to infer
> that a Webapp can span multiple contexts? How is this achieved? Obviously
> I don't know anything about Ant. And that's probably where I am going to
> look next.

There is a document in the Tomcat 4.0 source distribution
(catalina/docs/singlesignon.html) that talks about how to set this up.  You can
grab the binary and/or source nightly builds (or the milestone 1 release, which did
*not* have the feature we are discussing here) at <>.

To clarify things a little:

* The user's security identity (that is, the value returned by
  request.getUserPrincipal() or request.getRemoteUser()
  is propogated across all web applications.

* Cookies must be enabled for this solution to work.

* If you are using sessions, the user still ends up with a
  session *per webapp*.

The last issue is why the "single sign on" solution does not help you when your
application is trying to manage the security through sessions.  SSO only helps when
you are using container-managed security.

> However, I have essentially an identicle problem: I require 'single sign on'
> support for two seperate webapps, and I must be able to access the userId
> from servlets in either context, once again, I'm not sure how that is achieved.

As above, Tomcat 4.0 will do this for you *if* you are using container-managed
security (that is, security constraints in the web.xml files).

> I have the added requirement of binding database connections to sessions in
> each context. The sessions can be created and then destroyed when the user
> changes contexts, but I must be able to bind new db connections once the
> sessions are re-established.

This part of your app will still need to work the same way it always does (although
there is no requirement that the user have only one session -- they can certainly
have a session active on all of the apps they have touched).

> > Doing this with application-managed security is probably going to require
> > you to write customized interceptors (Tomcat 3.x) or valves (Tomcat 4.x).
> > You might want to reconsider whether you can use either container-managed
> > security with single sign on support, as described above, or combine all
> > your logically separate applciations into one context (from the point of
> > view of the servlet container).
> > >
> > > Larry
> > >
> I have been handling authentication within my servlets. I am forced to
> use a single context for each app since I am managing user information
> with the session tracking api. Although I have been having problems
> here with one app that happens to be an applet. I have had problems
> with null sessions and strange browser behaviour affecting my applet.
> It seems that it's time to upgrade to Tomcat 4.x. Last time I checked
> however the DBRealm feature was tagged as Experimental. An
> attractive feature that would integrate nicely esspetially for the single sign
> on requirement.

Well, I wouldn't go put a production site on it yet ...

But I would really appreciate people helping to test out all the new
functionality.  Look for a "milestone 2" release over the weekend that includes the
new single sign on support.

> Raimee


See you at ApacheCon Europe <>!
Session VS01 (23-Oct 13h00-17h00):  Sun Technical Briefing
Session T06  (24-Oct 14h00-15h00):  Migrating Apache JServ
                                    Applications to Tomcat

View raw message