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

[Anonymous]

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]

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]

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]

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?