• 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 ...
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
  • Mikalai Zaikin

Securing a JSF Logon

Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

I have written a simple web application, using JSF on Glassfish, that requires the user to logon via form based authentication. I have the basics working fine but cannot work out how I can achieve this using HTTPS. From searching the internet, it seems you can configure j_security_check to do this for you. However, a longstanding problem about this is that JSF does not have the ACTION capability but posts to managed beans. Has anyone any ideas about how to get around this?

In addition, once the user has successfully logged on and a session created, I would like to switch back to HTTP in order to save on the performance overhead. Is this a case of redirecting? Also, how do you configure the server to handle this?

Saloon Keeper
Posts: 27849
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 form-based authentication as defined in web.xml, you're asking for the JEE Container to manage security. You don't write any login code yourself - it's built into the container. The login process is done by hijacking the incoming request, replacing it with a request to the login (or loginfail) page, and processing the inputs (user ID and password). If the container determines the user is authorized, the hijacked request is popped out of the place where it was temporarily stored and processing is resumed as though login had never been requested. Except, of course, that if it hadn't, you'd never have been allowed to continue.

The transport mechanism (http/https) is also defined in web.xml. You can specify that certain URLS )as defined by URL patterns) MUST be accessed solely HTTPS. Other URLs can be HTTP or HTTPS access, and so to drop back to HTTP, just link to a URL with an "http:" in it.

Returning to the login process, login is forced whenever your web.xml matches the URL to a pattern that's under authentication control. The login action itself, incidentally, does not provide the full set of resources that a normal URL request can access, so login pages can't be built on complex servlet-dispatched frameworks such as JSF or Struts. Also, make sure that your login/loginfail pages don't attempt to access resources that won't be available until AFTER you've logged in!

JSF introduces one additional wrinkle to the equation. Since JSF URLs don't track directly, you sometimes have to force them or you'll end up with a security hole, as a secured resource gets accessed under a non-secured URL. You can avoid this by adding the <redirect/> element to a navigation item to cause it to be forced to use its "proper" URL.
Could you hold this puppy for a sec? I need to adjust this tiny ad:
a bit of art, as a gift, the permaculture playing cards
    Bookmark Topic Watch Topic
  • New Topic