Re: Form Based Authorization Question - David Haraburda - org.apache.tomcat.users

6 messages in org.apache.tomcat.usersRe: Form Based Authorization Question

From	Sent On	Attachments
David Haraburda	Jan 9, 2001 3:40 pm
Michael Wentzel	Jan 10, 2001 4:08 am
David Haraburda	Jan 11, 2001 3:07 pm
Craig R. McClanahan	Jan 11, 2001 3:23 pm
David Haraburda	Jan 11, 2001 4:25 pm
Craig R. McClanahan	Jan 11, 2001 4:36 pm

Subject:	Re: Form Based Authorization Question
From:	David Haraburda (dav...@haraburda.com)
Date:	Jan 11, 2001 4:25:53 pm
List:	org.apache.tomcat.users

Hi Craig,

Thanks for your help on this (and other issues). I am re-working security in our web application, and previously a user could go directly to a login page, log in, and be taken to their home, so I can't remove this functionality. What I did instead was this: I changed my "login" page to be a JSP that redirects a user to their home page, and then restricted this page. Thus, when a user hits it, if they are not logged in they will be sent to the real login page, then login, be redirected back to my page which then redirects them to their home. This seems to work pretty well.

My other question is this: Sometimes a person will need to login as one user, then logout and login as another. Is there anyway for me to "logout" or "unauthenticate" a user? Another curiosity stemming from this I have is:

In the Servlet spec (v 2.2, section 11.6) it states that "a servlet container is required to track authentication at the container level..."

As I understand it, this means my authorization/authentication information will be saved "across contexts" (ie, I can access a restricted servlet in a different context wihtout having to login again)

Does Tomcat do this? Where is this information stored, and what is the right way to invalidate it as I would need to do for a "logout" process? As far as I can tell it looks like it is just saved on the Request object (org.apache.tomcat.core.RequestImpl).

I really appreciate all your help.

Thanks once again,

David

"Craig R. McClanahan" wrote:

David Haraburda wrote:

Hi,

I am implementing the Java Servlet Form based login mechanism in my web application, and had a question. Is it possible for me to have a "default location" that a user goes to when they login?

You can do such things at the application level, but container-managed security will not do it for you.

Have you ever signed up for a subscription-based web site that uses BASIC authentication? What happens is that the username/password dialog box pops up -- you answer the questions -- and are then forwarded to whatever URL you originally asked for (without having to resubmit the request).

The form-based login mechanism simulates a popup by remembering your original request, and then automatically executing it after you have authenticated yourself. The user experience is pretty much the same thing.

In many instances, a user will go directly to the login JSP, rather than requesting a web resource first (which then causes Tomcat to display the login page, and then redirect back to the resource after authentication). If they haven't requested a resource, I'd like the login to take them to their "home" (different roles have different homes in my application). The only way I see right now is to check and see if session.getAttribute( "tomcat.auth.originalLocation" ) is null, but that seems rather naughty... is this the only way of doing it. I have written my own Realm object (that extends BaseInterceptor) for authentication/authorization purposes. Could something be done in there?

The way I program a webapp that uses container-managed security is to never explicitly reference the login page (if any) at all. That servlet container will do the right thing to authenticate a user, the first time that a protected page is requested, if and only if the container does not already know who the user is.

This approach means I can switch between authentication methods (BASIC, DIGEST, FORM, or CLIENT-CERT) with zero changes to my application logic.

From within the app, you can tell whether the user has been authenticated or not by calling request.getRemoteUser() or request.getUserPrincipal().

Thanks once again for the help,

	Start a set with this search
	Include this search in one of my sets
	Exclude this search from one of my sets