General J2EE: J2EE security -Common Login info for 2 application
- Posted by: fdsfdf sdfasd
- Posted on: February 15 2004 23:58 EST
We have implemented Container managed J2EE security in one of our applicationn(in web.xml) and we used request.getRemoteUser() method to get userid in the application after login.
But we have a different requirement to comply.
following is the scenario:
User will type URL1 :
say www.internetsite.com/context1 in the browser.
2) context 1 home page with login button will appear. User clicks on login button
3) it will show user id and password screen. user will enter user id and password in this screen and hit submit
4) it will now show a link to page
5) on click of hyperlink, it will open a new browser to call welcome page of /context2/.
6) But welcome page will appear only when request.getRemoteUser() has non-null value.
If null, re-direct to first login page again. means step 2.
step 6, I should get user id that user entered in step3. Because I call request.getRemoteUser() in the login action.
Always i get null here. Why?.
1) All are secured resources in web.xml.
Thanks in advance for ur help.
There is no J2EE-standard way to get two different web applications to share the same security context. Here is what I suggest you try:
1) Check your server's documentation and see if it has a mechanism supporting single-signon to multiple web applications. If it does, this is probably your best fix.
2) If you switch from form-based authentication to HTTP BASIC authentication, you can make both applications have the same BASIC authentication realm (as specified in the <realm-name> tag of the <login-config>).
If you do this, make sure the entire site is encrypted with SSL all the time. In other words, make sure your <transport-guarantee> is CONFIDENTIAL for all web resources in all your applications. This is the only way to make sure that BASIC authentication is really secure.
If neither option (1) or (2) works for you, then things are going to get very hard. You may need to switch from J2EE security to custom security. I suggest you pester your server vendor for options first, or maybe look for a third-party single-signon product.
If you are using Tomcat 5, look at the Single Sign-On Valve
If you are using Websphere 5, take a look at this: