You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Arieh Markel <Ar...@Central.Sun.COM> on 2000/02/11 00:58:09 UTC
login-config handling (was Re: Help with Interceptors)
> Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
> X-No-Archive: yes
> list-help: <ma...@jakarta.apache.org>
> list-unsubscribe: <ma...@jakarta.apache.org>
> list-post: <ma...@jakarta.apache.org>
> Delivered-To: mailing list tomcat-dev@jakarta.apache.org
> From: Assaf Arkin <ar...@exoffice.com>
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: Help with Interceptors
>
> > Since as Costin mentioned, this is not implemented yet, I will have to wait
> > until it is in (or implementing myself).
>
> Yes. Or help us get it implemented. I'm getting LDAP-based
> authentication to work, but I need Tomcat to be receptive of that. Any
> help would be greatly appreciated.
>
> arkin
I am willing to help get this implemented.
A question that rises is the following:
In my application, I define two contexts, each one with their respective
web-app:
default which is the "console" context
services which are things that plug in to the console
The default context is composed of several servlets that provide what
constitutes 'console' functionality (navigation, log viewer, alarms,
'service launching').
The 'launch' servlet serves as a registrar of servlets on the 'services'
context. In essence I am doing dynamic incorporation of servlets into the
engine.
The separation allows me to segregate the static portion from the
dynamic portion.
I would like that the same 'form-login-page' apply to both contexts.
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.
--
With regards to helping in the implementation, I need some guidance as to
the context on which the checking of prior access to the login-page has
been done.
What are the ideas of implementing this ?
--
Some of what I have in mind deal with checking HttpSession information.
In our implementation, I wanted to be able to handle the case of users
that do not accept cookies. I maintain a session-id keyed- Hashtable that
maintains valid sessions.
Session (in)existence is the determining factor for redirecting to the
login-page.
--
So in general, the default login page needs to be set whenever a URL access
that does not find a session (or a cookie) is detected.
--
With regards to the handling of the login information, I presume that the
code to support that needs to be in WebXmlInterceptor, right ?
Along the lines of adding a:
private void processLoginConfig ()
method.
The second part, as I see from the code could be in the context of
the ServletWrapper invocation and the subsequent RequestImpl setting of
the session.
--
Am I off in my assumption that login-page verification equates session
establishment ?
(That is at least how we treat it in our application).
--
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)
Re: login-config handling (was Re: Help with Interceptors)
Posted by Assaf Arkin <ar...@exoffice.com>.
> 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.
I guess my question, since I want to see one login for the entire realm
(and all contexts), is how can you specify that in the DD?
> 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 happened to SecurityProvider? I find it easy to work with a single
SecurityProvider where 'realm' is passed as an argument, rather than a
Realm per realm.
>
> >
> > 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.
If it can be done that way, all the better!
arkin
>
> Craig McClanahan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
Re: login-config handling (was Re: Help with Interceptors)
Posted by "Craig R. McClanahan" <cm...@mytownnet.com>.
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 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.
Craig McClanahan
Re: login-config handling (was Re: Help with Interceptors)
Posted by Assaf Arkin <ar...@exoffice.com>.
> 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 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.
> --
>
> With regards to helping in the implementation, I need some guidance as to
> the context on which the checking of prior access to the login-page has
> been done.
>
> What are the ideas of implementing this ?
In my understanding you need to somehow track the client to do that, so
that would map to the session. Before a new session is created (which
implies new user), you need to authenticate. Then you can use the cookie
(or session itself) to track the user.
Keep in mind that you might get two different sessions for two different
contexts.
> --
>
> Some of what I have in mind deal with checking HttpSession information.
>
> In our implementation, I wanted to be able to handle the case of users
> that do not accept cookies. I maintain a session-id keyed- Hashtable that
> maintains valid sessions.
You will need to embedd the session identifier into the URLs to carry it
from one request to another.
> --
>
> So in general, the default login page needs to be set whenever a URL access
> that does not find a session (or a cookie) is detected.
Yes, when a session is not found, regardless of whether it's cookie, URL
embedded, SSL, etc.
> --
>
> With regards to the handling of the login information, I presume that the
> code to support that needs to be in WebXmlInterceptor, right ?
Have no clue :-)
> Along the lines of adding a:
>
> private void processLoginConfig ()
>
> method.
>
> The second part, as I see from the code could be in the context of
> the ServletWrapper invocation and the subsequent RequestImpl setting of
> the session.
Probably in ServletWrapper. Instead of executing the requested Servlet
it will execute the Login servlet. The question that now arises is, how
do you tell the Login Servlet to jump into the requested Servlet when
the form is completed.
That is, if my request was for ServletX, I get into the login Servlet,
login, and if I'm successful it redirects me to ServletX.
> --
>
> Am I off in my assumption that login-page verification equates session
> establishment ?
Probably not. The session will be created whether or not you managed to
login. But you shouldn't be able to call any other Servlet until you
pass authentication.
Somehow there should be a way for the Servlet to either authenticate you
as 'anyone' if you don't pass the login test, or refuse to let you in
until you pass it.
There should also be a way to get into the login Serlvet and
reauthenticate.
arkin
>
> (That is at least how we treat it in our application).
>
> --
> 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)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org