Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

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

 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3695
IntelliJ IDE Java Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 190
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic