tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Johannes Fiala" <tom...@fwd.at>
Subject RE: request for solution, form-based authentication and programmatic authentication, repost
Date Mon, 05 May 2003 19:29:06 GMT
Hi Craig,

I have a different approach:
I have one central HandlerServlet which monitors and handles all accesses. 

In a Login servlet I create a Userroles HashMap which stores the roles a 
user has. I simply query these roles in the HandlerServlet whenever a user 
wants to access a JSP. 

I've used this approach successfully with a third party digital signature 
plugin and plan to use it for Client Certificate authentication. I think 
this is best, as it doesn't depend onto any container-specific 
authentication mechanisms. And it is quite secure, as long everything is 
done with https.

Johannes




"Craig Berry" <Craig.Berry@portblue.com> 
05.05.2003 20:31
Please respond to
"Tomcat Users List" <tomcat-user@jakarta.apache.org>


To
"Tomcat Users List" <tomcat-user@jakarta.apache.org>
cc

Subject
RE: request for solution, form-based authentication and programmatic 
authentication, repost






I asked this question last month, and didn't get any useful advice.
It's easy for a servlet to create a "one time identity" good enough for
calling back to EJB resources, but there's no documented way (that I
could find) to hook that identity into Tomcat's session management so
that the identity persists across requests.  If anybody reading this
knows of such a way, I'd love to hear it.

Meanwhile, the horrible kludge I implemented to get around this works as
follows:

1. The special access-granting page (your first-time-login info
gathering page) collects the username and password as you describe, and
stores them to the DB.  It also puts them into the session.  It then
sends a redirect back to the browser, pointing into the protected part
of your application.

2. JAAS intercepts the redirected request from the browser, and
redirects to the login form page.

3. The login form processor checks the session for the login info
stashed in step 1 above.  If present, it generates javascript onto the
page which populates the username and password onto the form, and then
submits the form automatically.

One tricky part of this scheme involves figuring out when to remove the
login object from the session, since you don't want it hanging around
longer than needed (since it would prevent normal logins from the
current session). 

-----Original Message-----
From: jarla [mailto:jarl.age.aanonsen@masterpieces.no] 
Sent: Monday, May 05, 2003 11:47 AM
To: tomcat-user@jakarta.apache.org
Subject: request for solution, form-based authentication and
programmatic authentication, repost


I am developing a web application based on tomcat 4.0 and servlets. The
application utilizes the form-based authentication and JDBCRealm 
mechanisms.

The authorization and authentication should work like this:

First-time users seeking access, submits a form containing requested 
user name, password and some personal information. This authorizes the 
user for later occations (sessions) and grants immediately access. 

User authorized on a prior occation (session) seeking access, submits a
login form. 

The latter function is handled by the form-based authentication 
mechanism.

I can not, however, see a solution for the first function. I.e how to
avoid that the first-time user submits a personal information form and
then submits a login form.

Is there any way to authenticate a user programmatically?
If not is there any other way at all?

In advance, thanks for any contributions,
Jarl Aanonsen
jarla@netcom.no


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message