Hi everyone.
Been fiddling around with Glassfish and got some different behaviour than the one I was expecting. Basically the authentication mechanism is working as I wanted but the HttpServletRequest isUserinRole method isn't. Don't really know if this is expected but since it didn't seam logical to me I'm posting it here.
This is how I replicate the described behaviour:
Configured a new FileRealm on glassfish:
JAAS Context : fileRealm
key file : some file
assign group :
Changed the Security configuration for the realm only in this way :
Default Principal To Role Mapping : ENABLED
Now I create a user on the new fileRealm with the following settings:
username: rui
groups : admin,dude
Now , got a simple webapp configured like so :
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="
http://java.sun.com/xml/ns/javaee"
xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
version="2.5">
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>fileRealmTesting</realm-name>
</login-config>
<security-constraint>
<web-resource-collection>
<web-resource-name>Assert Authentication</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
</web-app>
and there is a JSP there with code like this:
<%=request.getUserPrincipal().toString()%> <br>
<%
for (String group: new String[]{ "admin", "dude", "superdude" }) {
out.println("<br> User is in group " + group + ": " + request.isUserInRole(group));
}
%>
Basically , now when I try to visit that JSP I authenticate with user Rui and the correct password.
When on the web.xml the auth-constraint is set to role-name: admin I manage to login correctly and see the webpage with some outputs
When on the web.xml the auth-constraint is set to role-name: superdude I manage to login but get a 403 error straight away.
When on the web.xml the auth-constraint is set to role-name: dude I manage to login correctly and see the webpage with some outputs
This small test tells me that authentication and authorisation is working fine. BUT , in both instances of the test that succeed ( the admin and dude role-name setup) the output from the jsp is :
rui
User is in group admin: false
User is in group dude: false
User is in group superdude: false
This basically tells me that the isUserInRole() method simply isn't working the way I expected or at least the output of the method is not coherent with the behaviour of the security setup of the application.
Now, another piece of the trivia: if I add the following lines to the web.xml :
<security-role>
<description>admin people</description>
<role-name>admin</role-name>
</security-role>
<security-role>
<description>A simple dude</description>
<role-name>dude</role-name>
</security-role>
<security-role>
<description>A super dude</description>
<role-name>superdude</role-name>
</security-role>
The result of the JSP output for both instances is:
rui
User is in group admin: true
User is in group dude: false
User is in group superdude: true
So basically if I declare the roles in the web.xml file the output of the isUserInRole() seams to be correct now. My problem is : I can't really have the security-roles defined in the web.xml file because they are created dynamically through the user interface of the application being developed.
Now, I know that because I'm using FileRealm I can cast the Principal to FileRealmUser and in that class we got a "getGroups" method that should give me some results . I haven't tested this to see if the results are correct or not because I simply do not want to use it. I need my app to take in authentication from any kind of realm, including custom realms that might not have that implemented. ( but I do admit it would be a good test , just to check what is going on in there)
So, now for my questions :
1st - Is this expected behaviour? If so , explain why, because it doesn't seam logical to have one thing working and the other not working if the descriptor is lacking stuff. If the descriptor is lacking stuff that is mandatory for the proposed setup then either both don't work, or both work... not one or the other.
2nd - If this is not the expected behaviour, which is?
3rd - Is there a Workaround for this situation?
Thanks all for your help, or at least for taking the time to read the post ! :)
Rui
[Message sent by forum member 'syshex' ]
http://forums.java.net/jive/thread.jspa?messageID=373343