I'm having the same problem with 3.0.3 using Jetty. In debug mode it even says that the user is in the role and still returns false. In my case I have a role ADMIN, and request.isUserInRole("ADMIN") is returning false although the log indicates it should be true(see log below).
Have you gotten anywhere with this?
Here's the log:
14:31:38,984 DEBUG [JBossUserRealm#StoryDB]authenticated: testUser
14:31:38,984 DEBUG [JBossUserRealm#StoryDB] setting JAAS subjectAttributeName(j_subject) : Subject:
14:31:38,984 DEBUG [JBossUserRealm#StoryDB]JBossUserPrincipal: testUser is in Role: ADMIN
I've made some progress with my problem and there is a chance this might help you as well. In my case the result of isUserInRole is tied to my directory context. request.isUserInRole and request.getUserPrinciple only returns valid results under the context in which the login was made.
So if I require a user to login when he hits a page under /myApp/admin/, only pages under /myApp/admin/ returned a non-null userPrinciple and valid isUserInRole. Even after I login to an admin page when I return to a page a directory up like /myApp/test.jsp, getUserPrinciple returns null(and of course isUserInRole returns false).
I'm not sure that this is the required behavior by spec. Requiring people to login at "/" for the web app fixes my problem but causes others. I would have expected the UserPrinciple to be valid for the entire WAR context.
I'm not sure that this will help you, but I thought I'd pass it along.
Thx for the input. I was thinking for a while that I was the only one with this problem ;-)
I've since tried with DEBUG on and get the same thing as you mentioned, with it printing out that the user has the required role, yet isUserInRole() returning false.
It is interesting that the authentication seems to go under the context path. I cannot believe that this is part of the J2EE spec though. If a user is authenticated for a web-app they should have the security credentials for the whole of that app, from the point they authenticate.
In my app, I have an unprotected page (context path /shop), in which I want to add a hyperlink to a protected page IF the user has the given role. If the user is not logged in, I would just not display this hyperlink, and I wouldnt expect J2EE to authenticate the user at this point. If the user logs in under a context path of /login and then they go to the unprotected page, isUserInRole() and getUserPrincipal() return that the user is not authenticated and doesnt have any roles ! even though they have been authenticated.
Can somebody from the JBoss dev team please comment on what the J2EE spec says on this point ?
Maybe i'll wait for the next release :-(
> It is interesting that the authentication seems to go
> under the context path.
I have come across this sort of thing in the past and I believe this is the expected behaviour - if you aren't under one of the security constraints then you won't have access to the security information. I agree it seems a bit counter-intuitive.
> I cannot believe that this is part of the J2EE spec
> though. If a user is authenticated for a
> web-app they should have the security credentials for
> the whole of that app, from the point they authenticate.
I don't think the servlet spec is very clear on this issue (though new releases may try to be more specific). So the bottom line is that you can't depend on it.
I ran into the same issue, and finally wrote a work around to mirror the authorization state in the session so it could be retrieved on unrestricted pages. If you’re interested, you can get the code from http://www.huchley.com/nerds/jboss.jsp#isUserInRole
I hope this changes in 4.0, it's a headache if you use role based security on a site with any unrestricted pages.
Just as an update, the servlet 2.4 spec explicitly states:
(SRV.12.10 Login and Logout)
Being logged in to a web application corresponds precisely to there being a valid non-null value in getUserPrincipal method, discussed in SRV.12.3
Which doesn't happen at the moment. So I would hope that this behaviour will be changed at some point (if it hasn't already).