• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Liutauras Vilda
  • Jeanne Boyarsky
  • paul wheaton
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Henry Wong
Saloon Keepers:
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Tim Moores
  • Mikalai Zaikin
Bartenders:
  • Frits Walraven

Authentication nad authorization in JSF

 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
HI, i am trying to do authentication in JSF app, but i stuck. I found, one way is to do it by the JAAS and some realm. I choose jdbcRealm and everything was fine, until I need to display some message to the user(eg you have enterred wrong password(but i do not want to redirect him elsewhere). Another probem is how to redirect the user after the login. Is there any way to do it? I try to google it, but i have found nothing, which was usefull. And my last questing is. Do I have to you the form with j_username, j_password.., or can I do it by some JSF components?
 
Saloon Keeper
Posts: 28320
210
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When you use a Realm and the web.xml security definitions, you're employing J2EE standard container-manages Authentication and Authorization. This is a pretty well-documented system and it's fairly simple, but extremely effective. It's also extremely secure, which is something that I haven't seen much of in "do-it-yourself" security systems.

You should NEVER tell a user "incorrect password". That tells them that they know the userid, so they only have to work half as hard to break in. That's why really secure systems will only say "invalid user id/password". It keeps the Bad Guys guessing. Security is the one place where being helpful is not a virtue.

web.xml allows to define both a login view and a loginfail view. Loginfail is - not surprisingly - what displays when you enter credentials on the login page and they are not correct. Usually my loginfail pages are identical to the login pages and contail a j_username and j_password form just like the login page, but usually have the caption "Login failed" on them. Which is as close as I'll get to saying "Invalid Password".

The login/loginfail pages aren't actually managed by the webapp. They're managed by the webapp container. As a result, they have certain limitations and should be kept simple. And yes, the login action processor for the container does expect a form with fields named "j_username" and "j_password" exactly as spelled/capitalized.

J2EE doesn't route a user after login for a number of reasons. One of the primary strengths of the J2EE security system is that it acts as wrap-around protection for the webapp URLs. One of the most common ways to exploit do-it-yourself security is by submitting a URL that bypasses the DIY security. In J2EE security, NOTHING bypasses security. The URL will never reach the webapp at all unless the user is authenticated and authorized. Since the container doesn't route post-login actions, this allows a secure direct access to commonly-used pages. It also factors in when you're using a site-wide security system instead of a per-application security context. In such cases, you might have logged in to another app entirely, so this app would never actually see a login event. And no, there's aren't any J2EE login/logout events per se. precisely because of such considerations. If you must, you can fake it. put a filter in the webapp and monitor the incoming HttpRequests for a change in the userid property. You've just logged in when the userid is no longer null. "Logout" detection, of course, is done by employing a Session Listener to detect Session destroy events.
 
Lukas Hnatuk
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Once again thank you very much.)))) It was you(about moth ago here) who told me, that DIY filter is stupid think and tell me to do it by JAAS and it is you again, who help me out of darkness:)))
 
Poop goes in a willow feeder. Wipe with this tiny ad:
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
reply
    Bookmark Topic Watch Topic
  • New Topic