Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Message-Id: <200002111616.JAA19300@durango.Central.Sun.COM>
Date: Fri, 11 Feb 2000 09:16:12 -0700 (MST)
From: Arieh Markel <Arieh.Markel@Central.Sun.COM>
Reply-To: Arieh Markel <Arieh.Markel@Central.Sun.COM>
Subject: Re: login-config handling (was Re: Help with Interceptors)
To: tomcat-dev@jakarta.apache.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: yrvRcfuzeGgz/WoKpkEfkA==


>
> Assaf Arkin wrote:
> 
> > > I am willing to help get this implemented.
> >
> > Excellent.
> >
> > > Inspection of the spec (2.2) indicates that the form-login-page is
> > > the
> > >
> > >         "location in the web app where the page that can be used for
> > >         login can be found"
> > >
> > >
> > > This appears not to address my need, since I would like to be able to have
> > > the same login page for multiple web apps.
> >
> > Actually I think that the form is specific for a context. Since you
> > specify it in the deployment descriptor, each context will use a
> > different form, and different session.
> >
> 
> What you say is true about sessions (they are specific to a servlet context),
> but not necessarily true for general user authentication.  The 2.2 spec allows 
a
> container to implement "single sign on" authentication for multiple web apps 
on
> the same server, although it gives precious few details on how to do this in a
> portalble manner.  I would hope that would be clarified in the next round.
> 
> In the Catalina architecture this would not be terribly hard to implement,
> because you can attach a Realm at any level in the containment hierarchy.
>  However, there'd still be some issues about how you configure the session id
> cookies for each app, plus how to decide which context to use for the actual
> authentication rules.

What Craig (and the spec) mention here is key to understanding that the
'Realm' objects need to have scope across all Contexts (perhaps through the
ContextManager).

It would be then up to the implementor to group different contexts into
(shared) realms.

> 
> >
> > What you want to do is be able to carry the login from one context to
> > another. Once you logged into one context, you are automatically logged
> > on in the other. Have no clue how to make it happen, but I think that's
> > how it should work.
> >
> 
> What we're saying is that the values returned by getRemoteUser() and
> getUserPrincipal() would be global to multiple apps, with only a single login
> challenge.  The sessions would still be unique per context, but you'd be able 
to
> count on the fact that the container authenticated the user for you.

In the current implementation, we went with an approach that different
contexts share a session registry.

We did this indirectly by defining a SessionTable object associated with
the Context(s).

All contexts refer to the same session table.

The key to the session table is based on the sessionId that we generate.
The value of the session table entry is the HttpSession object obtained from
the request.

--
We will need to modify this once security is implemented and in place.

Arieh
--
 Arieh Markel		                Sun Microsystems Inc.
 Network Storage                        500 Eldorado Blvd. MS UBRM11-194
 e-mail: arieh.markel@sun.COM           Broomfield, CO 80021
 Let's go Panthers !!!!                 Phone: (303) 272-8547 x78547
 (e-mail me with subject SEND PUBLIC KEY to get public key)