aspose file tools*
The moose likes JSF and the fly likes Trouble with FORM auth method in JSF login process Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSF
Bookmark "Trouble with FORM auth method in JSF login process" Watch "Trouble with FORM auth method in JSF login process" New topic
Author

Trouble with FORM auth method in JSF login process

Alexander Mitenko
Greenhorn

Joined: Mar 11, 2009
Posts: 8
Here is /secure/welcome.xhtml text after login process:

I've four pages for test:

web.xml:

/welcome.xhtml have a button:
PrimeFaces namespace <p:
LoginBean.java part for login processing:


What is wrong here?

Server log (FINEST Security log enabled):
Alexander Mitenko
Greenhorn

Joined: Mar 11, 2009
Posts: 8
Help me, please, my mind becomes rot in these naughty faces
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16305
    
  21

Did you define a Security Realm for your webapp?

When you use the J2EE standard security services, the security provider (Realm) is imposed as part of the external context definition, not coded into the webapp. That's because the authentication and authorization is handled by the webapp server. Realms are plug-ins, which allows you to reconfigure your security provider without making application changes.


Customer surveys are for companies who didn't pay proper attention to begin with.
Alexander Mitenko
Greenhorn

Joined: Mar 11, 2009
Posts: 8
Yes, of course.
That is obvious from log.
Else user archimage cannot login, but here login was successful.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16305
    
  21

Actually, the downside of detailed logs is that obvious tends to get buried. I asked because I saw an explicit login request in code and it's unfortunately common that people think that user-written "security" systems can make use of the web.xml config info designated for use by the container security system,

One thing that is missing from your example, I believe, is the "catch" part of the "try" block around your login code and a print of the stacktrace that would have been captured at that point.

It may not be important, because the most likely explanation is that you haven't mapped the role named "admin" to the user ID "archimage" in your Realm authentication and authorization "database". If that relationship doesn't exist, then the "503" page is exactly what users would see, ubless you replaced it with a custom "You can't do that - you're not authorized" message page of your own design.
Alexander Mitenko
Greenhorn

Joined: Mar 11, 2009
Posts: 8
Tim Holloway wrote:Actually, the downside of detailed logs is that obvious tends to get buried. I asked because I saw an explicit login request in code and it's unfortunately common that people think that user-written "security" systems can make use of the web.xml config info designated for use by the container security system,

Explicit login request based on Servlet 3.0 recommended login process and uses container security in fact. At this moment I haven't my own security system
Tim Holloway wrote:One thing that is missing from your example, I believe, is the "catch" part of the "try" block around your login code and a print of the stacktrace that would have been captured at that point.

catch block:

But here is no exception and stacktrace! Login was successful, it's logged, as I said before. Here is authorization, not authentication troubles...
Tim Holloway wrote:It may not be important, because the most likely explanation is that you haven't mapped the role named "admin" to the user ID "archimage" in your Realm authentication and authorization "database". If that relationship doesn't exist, then the "503" page is exactly what users would see, ubless you replaced it with a custom "You can't do that - you're not authorized" message page of your own design.

403 page shown, not 503...
Alexander Mitenko
Greenhorn

Joined: Mar 11, 2009
Posts: 8
Tim Holloway wrote:It may not be important, because the most likely explanation is that you haven't mapped the role named "admin" to the user ID "archimage" in your Realm authentication and authorization "database". If that relationship doesn't exist, then the "503" page is exactly what users would see, ubless you replaced it with a custom "You can't do that - you're not authorized" message page of your own design.

My realm configured by the right way - user archimage have an admin role and registered in the "file" realm, mapped in web.xml.
May be troubles in other GlassFish config or project deployment places?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16305
    
  21

If I was to assert that my configuration was perfect, I'd have managed to mis-capitalize something, transpose 2 characters (preferably something narrow like "ii" so it's hard to see) or done something otherwise blatantly wrong that would take me 3 days to spot or 5 minutes for someone who didn't "know" what was there. This is because machines in general and computers specifically delight in making me look like an idiot.

There are no bugs I know of in the Glassfish security system. You might have missed configuring something in sun-web.xml, but you didn't provide a copy of that file.

You authenticated properly, as demonstrated by the fact that it's trying to bring up the post-login JSF View. However, you're not authorized to do so. Normally this would indicate that the userid/password informaiton in your user's account configuration was correct, but the userid/role collection did not contain the role "admin" for that userid.
Alexander Mitenko
Greenhorn

Joined: Mar 11, 2009
Posts: 8
Tim Holloway wrote:If I was to assert that my configuration was perfect, I'd have managed to mis-capitalize something, transpose 2 characters (preferably something narrow like "ii" so it's hard to see) or done something otherwise blatantly wrong that would take me 3 days to spot or 5 minutes for someone who didn't "know" what was there. This is because machines in general and computers specifically delight in making me look like an idiot.

That is obvious for me, as a computer professional with 20 years of IT experience and was checked first
Tim Holloway wrote:There are no bugs I know of in the Glassfish security system. You might have missed configuring something in sun-web.xml, but you didn't provide a copy of that file.

Here was a trouble!
I'd missed role-mapping section in that file, thanks for Your advice!
But for what purposes that information must be doubled here?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16305
    
  21

You have 2 different types mappings.

One is the mapping of roles to a URL pattern. That's done in web.xml

The other is the mapping of roles to a user. That's done in the "security database", using the term "database" very abstractly.

In order to allow even more abstraction, there are mechanisms that allow mapping an external role name to an internal role name. That's useful for cases where the site-wide role named "admin" might have to apply to a web.xml role name of "sysop" in one webapp and "web-admin" in another webapp.

Sun offers an additional level of confusion with their "groups". I'm not clear if they're used for internal-to-external role mapping or for a convenient way to bundle users or roles together and treat them as units. I'm more of a Tomcat person overall, so I'd have to RTFM to be able to sort it all out.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Trouble with FORM auth method in JSF login process