aspose file tools*
The moose likes Tomcat and the fly likes Tomcat5, Forms based authentication and poor man's Single SignOn Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » Tomcat
Bookmark "Tomcat5, Forms based authentication and poor man Watch "Tomcat5, Forms based authentication and poor man New topic
Author

Tomcat5, Forms based authentication and poor man's Single SignOn

Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Hi there,
I need to login to a backend system in a tomcat servlet. The username/password is the same as in Tomcat (they talk to the same LDAP). So I thought I could use the tomcat login (forms based) to get the username/password and do the authentication....
But I'm clueless where to start. How can I intercept the username/password before (or after) Tomcat uses it for authentication?
Any hint appreciated!
;-) stw
Mike Curwen
Ranch Hand

Joined: Feb 20, 2001
Posts: 3695

Container Managed Authentication (CMA) is just that; container-managed.

Arguments rage over whether the spec allows leeway or not, and I'm sure different containers allow different things, but as far as I know, in Tomcat, there is very little opportunity (read: none) to intercept the CMA process and do either pre- or post- processing. At least none that are trivial.

Many people have identified this as a weakness of the spec. For example: what if they want to create a number of objects on successul login, and place them in the session? Or your example, of authenticating against another system.
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Ok, if the front door is locked... lets use the backdoor then?

I did understand form based authentication this way:
User -> REQ Protected Realm -> Resp Login.form -> POST j_username, j_password -> j_security_check -> (if success) -> Resp (Session-Cookie) + Protected Realm.

What I didn't understand (yet): how does the Container know where to redirect the user after successful login (is there another field)?

Using that mechanism we could alter the login.html and post the login request to an unprotected servlet that in return does all the nice logins in legacy systems etc. AND uses an HTTPURLconnection to authenticate and put the Cookie in the original response. This way the container remains, well the container (black box).
Would that work?
;-) stw

P.S.: Or is there an API to provide your own authentication scheme?
Ken Loh
Ranch Hand

Joined: Feb 16, 2005
Posts: 190
Stephan's suggestion has interested me a lot. If it works, it would definitely alleviate the pain many developers are sufferring in the aspect being discussed.

However, "post the login request to an unprotected servlet that in return does all the nice logins" as what Stephan said, could not be possible as in an unsecured realm, getPrincipal() and its counterparts return null. Can't do much really with null object (*sigh*).

If anyone has a breakthrough or two in this aspect, appreciate it if you could advise ?

Originally posted by Stephan Wissel:
Ok, if the front door is locked... lets use the backdoor then?

I did understand form based authentication this way:
User -> REQ Protected Realm -> Resp Login.form -> POST j_username, j_password -> j_security_check -> (if success) -> Resp (Session-Cookie) + Protected Realm.

What I didn't understand (yet): how does the Container know where to redirect the user after successful login (is there another field)?

Using that mechanism we could alter the login.html and post the login request to an unprotected servlet that in return does all the nice logins in legacy systems etc. AND uses an HTTPURLconnection to authenticate and put the Cookie in the original response. This way the container remains, well the container (black box).
Would that work?
;-) stw

P.S.: Or is there an API to provide your own authentication scheme?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Tomcat5, Forms based authentication and poor man's Single SignOn