• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Form Authentication not working

 
B Nirvan
Ranch Hand
Posts: 82
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am trying to set up FORM based container authentication. I am facing some issues that are discussed below.

Firstly, the authentication is not triggered when I use the following in security-constraint in web.xml.

However, if I change the <url-pattern> to /* as pasted below, it works and the user is asked to authenticate himself.


The public xhtml page which tries to access the secured content (adminPage.xhtml) is given below.


Secondly, if I use <a href=""> instead of <h:commandLink> in the page above, the authentication is triggered and user is asked to authenticate.

Any ideas why I have such strange behaviours ?

regards,
Nirvan.


 
Brendan Healey
Ranch Hand
Posts: 218
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's tricky to setup, one of the features of good security is of course that it doesn't
give too much feedback to hackers, however this mindset seems to permeate through
so that application developers never know how to configure the software due to lack
of error messages. However, you may have forgotten this:



Regards,
Brendan.
 
B Nirvan
Ranch Hand
Posts: 82
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Brendan,
Thanks for the response. However, I have already configured the <login-config> element in the web.xml file. I am pasting the complete security segment of the web.xml to rule out any mistakes in the same.


regards,
Nirvan.
 
B Nirvan
Ranch Hand
Posts: 82
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am really confused with the authentication mechanism used by glassfish. When I try to access secured web page, the authentication seems to be triggered, as indicated by the glassfish log. But somehow the user is authenticated even if he is not logged on. Here is the glassfish log file when the user tries to access secured page without logging on.



As can be seen the user gets the permission, But he is not logged on !

regards,
Nirvan.
 
Brendan Healey
Ranch Hand
Posts: 218
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Hi Nirvan, I've checked through what you have against my own web.xml, the only difference I
can see is that I have an <auth-constraint> directly after my <web-resource-collection> for the
secure pages. You have another <web-resource-collection> in between, but it's far from obvious
to me whether this will help or not, but it's got to be worth a try.

Also, do you have a <welcome-file> specified? I think this is pretty important because following
a successful login this is where the security system will take you, but my guess is this is just in
a different part of your file.



So perhaps you need to duplicate the <auth-constraint> section, have one after the
faces pages and one after the non-faces pages??

Regards,
Brendan.
 
Tim Holloway
Saloon Keeper
Posts: 18300
56
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, it may be more basic than that. When you use raw HTML, the URL is exactly as typed. But the JSF elements often prefix the application context on the submitted URL.

In other words, if your app is deployed under "myapp" (http://www.myserver.com/myapp), the JSF URL constructed would include the "myapp" part, although that would be stripped again from the URL before the security pattern-matcher got to it.

Another and more devious problem may be because you're doing this as an Action. I'm not sure about when you do a direct View reference, but when you invoke an Action method and your target is a secured resource, you need to include the "redirect" qualification. That's because JSF doesn't track URLs directly, and without the redirect, the submitted request will go in under the old nonsecured URL, even though the target URL is secure. And the container security system vets based on incoming URL, NOT on target resource!

Adding "redirect' (or the "<redirect/> element to a faces-config navigation) will cause the request to be redirected in under the secured URL and that will cause the security URL filter to kick in properly.
 
B Nirvan
Ranch Hand
Posts: 82
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:
Another and more devious problem may be because you're doing this as an Action. I'm not sure about when you do a direct View reference, but when you invoke an Action method and your target is a secured resource, you need to include the "redirect" qualification. That's because JSF doesn't track URLs directly, and without the redirect, the submitted request will go in under the old nonsecured URL, even though the target URL is secure. And the container security system vets based on incoming URL, NOT on target resource!

Adding "redirect' (or the "<redirect/> element to a faces-config navigation) will cause the request to be redirected in under the secured URL and that will cause the security URL filter to kick in properly.


Hit the hammer at the right spot. I changed to outputLink instead.

Tim, Brendan thanks very much for investigating the problem.

regards,
Nirvan
 
Pramod Kankure
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I was getting a similar problem. In my case the issue was with the way you specifiy URL_Pattern in Security_constraint. You should always prefix it with /faces/
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic