Having serious trouble configuring Authorization

[Carlos Jorge Tavares Ferreira]

Hi,

I'm facing several issues trying to configure my web app, because nothing is working as I would expect.
I've defined a JDBC Realm on my glassfish v3 installation, and authentication is working properly, redirecting
to the error page when I insert the wrong credentials. So far, so good.

The first problem I've detected is that the app is allowing access to all resources, even those that match the url pattern defined in my security constraints.
It complete ignores the values on my groups table, used in the JDBC Realm.

The second problem is related to the error pages I'm using. I've defined 3 error pages: 403.jsp, 404.jsp and 500.jsp.
If i'm not authenticated and request a resource that doesn't exist (e.g., http://localhost:8080/portal/login.xhtml or http://localhost:8080/portal/login2.jsp), the app shows me the 403.jsp page, as expected. But if I'm authenticated the behavior changes, i.e., if I request a resource that doesn't exist with the xhtml extension, it shows me the 500.jsp, but if I request a non-existing resource with other extension, it shows me the 403.jsp page. But there's an additional problem, both the pages show up scrambled, because the css file and all the images are being blocked.

Here is my web.xml:

    
<web-app version="3.0" 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_3_0.xsd">
    <display-name>Portal de Serviços</display-name>
    <context-param>
        <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
        <param-value>client</param-value>
    </context-param>
    <context-param>
        <param-name>javax.faces.PROJECT_STAGE</param-name>
        <param-value>Production</param-value>
    </context-param>
    <context-param>
       <param-name>javax.faces.FACELETS_LIBRARIES</param-name>
       <param-value>/WEB-INF/menu-taglib.xml</param-value>
    </context-param>
 
    <context-param>
        <param-name>com.sun.faces.resourceUpdateCheckPeriod</param-name>
        <param-value>-1</param-value>
    </context-param>
    <context-param>
        <param-name>com.sun.faces.validateXml</param-name>
        <param-value>true</param-value>
    </context-param>
 
    <servlet>
        <servlet-name>Faces Servlet</servlet-name>
        <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>Faces Servlet</servlet-name>
        <url-pattern>/faces/*</url-pattern>  
    </servlet-mapping>
    
    <welcome-file-list>
        <welcome-file>index.html</welcome-file>
    </welcome-file-list>

    <error-page>
        <error-code>404</error-code>
        <location>/errors/404.jsp</location>
    </error-page>
    <error-page>
        <error-code>403</error-code>
        <location>/errors/403.jsp</location>
    </error-page>
    <error-page>
        <error-code>500</error-code>
        <location>/errors/500.jsp</location>
    </error-page>

    <security-constraint>
        <web-resource-collection>
            <web-resource-name>Restricted methods</web-resource-name>
            <url-pattern>/*</url-pattern>
            <http-method>DELETE</http-method>
            <http-method>PUT</http-method>
        </web-resource-collection>
        <auth-constraint/>
    </security-constraint>

    <security-constraint>
        <display-name>SecurityConstraint</display-name>
        <web-resource-collection>
            <web-resource-name>protected</web-resource-name>
            <url-pattern>/secure/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>admin</role-name>
            <role-name>superuser</role-name>
            <role-name>user</role-name>
        </auth-constraint>
    </security-constraint>

    <login-config>
        <auth-method>FORM</auth-method>
        <realm-name>myJDBCRealm</realm-name>
        <form-login-config>
            <form-login-page>/login.jsp</form-login-page>
            <form-error-page>/loginError.jsp</form-error-page>
        </form-login-config>
    </login-config>

    <security-role>
        <role-name>admin</role-name>
    </security-role>
    <security-role>
        <role-name>superuser</role-name>
    </security-role>
    <security-role>
        <role-name>user</role-name>
    </security-role>
</web-app>

And my sun-web.xml:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Application Server 9.0 Servlet 2.5//EN" "http://www.sun.com/software/appserver/dtds/sun-web-app_2_5-0.dtd">
<sun-web-app error-url="">
    <context-root>/portal</context-root>
    <security-role-mapping>
        <role-name>user</role-name>
        <group-name>user</group-name>
    </security-role-mapping>
    <security-role-mapping>
        <role-name>superuser</role-name>
        <group-name>superuser</group-name>
    </security-role-mapping>
    <security-role-mapping>
        <role-name>admin</role-name>
        <group-name>admin</group-name>
    </security-role-mapping>
    <class-loader delegate="true"/>
    <jsp-config>
        <property name="keepgenerated" value="true">
            <description>Keep a copy of the generated servlet class' java code.</description>
        </property>
    </jsp-config>
</sun-web-app>

I've defined 2 users on the DB, one associated with the group 'user' and another associated with the group 'xpto'.
Both of them are able to access http://localhost:8080/portal/faces/secure/home.xhtml

I'm really desperate for help, I don't know what else I can try.

Hope someone can help me figure out what the problem is.

Kind regards,

Carlos Ferreira

[Tim Holloway]

Welcome to the JavaRanch, Carlos!

It's not a surprise that you'd get a "500" error on JSF page requests if you didn't have an xhtml file that matched the JSF URL. A 500-series error indicates that the FacesServlet ran into an error while processing the request. For a non-JSF URL, the FacesServlet wouldn't be involved.

I'm afraid I can't see how you should be able to retrieve resources that are accessed under the "secure" URL pattern, however. Something you're doing doesn't match what I'm thinking you're doing.

[Carlos Jorge Tavares Ferreira]

Hi Tim,

Thanks for your reply.

All my pages are under the secure folder, and I only want authenticated/authorized users to access those files.
My main problem right now is that although I specified a security constraint:

# <security-constraint>  
#         <display-name>SecurityConstraint</display-name>  
#         <web-resource-collection>  
#             <web-resource-name>protected</web-resource-name>  
#             <url-pattern>/secure/*</url-pattern>  
#         </web-resource-collection>  
#         <auth-constraint>  
#             <role-name>admin</role-name>  
#             <role-name>superuser</role-name>  
#             <role-name>user</role-name>  
#         </auth-constraint>  
#     </security-constraint>

Any authenticated user can access a page under that folder (e.g., http://localhost:8080/portal/secure/home.xhtml), even if the user doesn't
have an adequate role.

Am I thinking the wrong way? Isn't the security constraint supposed to block access to those pages?

Kind regards,

Carlos Ferreira

[Tim Holloway]

Your URL pattern for security is not correct for Faces requests. It would have to be "/faces/secure/*" for that, based on your Faces url-pattern.

[Carlos Jorge Tavares Ferreira]

Sorry, my mistake, that was the web.xml I had yesterday.
I've been making several changes to try to make it work and when I replied
to your first post and copied the security constraint from my initial post instead of
copying the one I'm using now, and where both url patterns (Faces Servlet and Security Constraint)
have the same value: *.xhtml
The problem still persists.


The curious thing about this is that if I remove this constraint:

# <security-constraint>
# <web-resource-collection>
# <web-resource-name>Restricted methods</web-resource-name>
# <url-pattern>/*</url-pattern>
# <http-method>DELETE</http-method>
# <http-method>PUT</http-method>
# </web-resource-collection>
# <auth-constraint/>
# </security-constraint>

The application starts having the opposite behavior, i.e., it blocks all users from accessing protected pages...

Any idea?

Kind regards,

Carlos Ferreira

[Tim Holloway]

I wouldn't use "*.xhtml" as a url pattern if you're using "*.xhtml" resources. It confuses the difference between webapp resources and URLs and may confuse the FacesServlet. It's more common to use something like "*.jsf", so that a "http://localhost:8080/myapp/secure/hello.jsf" resolves to the "/secure/hello.jsf" webapp resource. The URL mapping, as its name implies, works on submitted URLs and doesn't protect resources.

[Carlos Jorge Tavares Ferreira]

Hi Tim,

First of all, I would like to thank all your efforts to help me solve this.

Maybe I'm not explaining correctly my problem.

I'll try to put it in a simpler way:

- Two users, userA and userB

userA has one entry on the groups table, associating him to the 'user' role
userB has one entry on the groups table, associating him to the 'xpto' role

Considering this security constraint:

 
   <security-constraint>    
         <display-name>SecurityConstraint</display-name>    
         <web-resource-collection>    
             <web-resource-name>protected</web-resource-name>    
             <url-pattern>/secure/*</url-pattern>    
         </web-resource-collection>    
         <auth-constraint>    
             <role-name>admin</role-name>    
             <role-name>superuser</role-name>    
             <role-name>user</role-name>    
         </auth-constraint>    
     </security-constraint>  

What should happen if both users try to access the page http://localhost:8080/portal/secure/home.xhtml?

Shouldn't the application show the 403 error page for userB, or I'm interpreting the usage of the constraint the wrong way?

Kind regards,

Carlos Ferreira

[Tim Holloway]

It "should" work that way. unless some other security constraint overrides it. I've done exactly that for years with no problem.

Most likely I'm assuming you're doing something right and you don't know what you're doing wrong. That's the kind of thing that's hard to catch unless you have someone actually watching you do it.