[ 
https://issues.apache.org/jira/browse/GERONIMO-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462371
 ] 

Jeff Genender commented on GERONIMO-2695:
-----------------------------------------

Also...I think I see a possible issue in your web.xml.

Looking at your web.xml it appears that your security constraints are 
overlapping.  This can cause problems.  You can either make it more specific as 
to what is secure and what is not, or you can try changing the order of 
precedence (which is a shot in the dark).

Try swapping the order of how they appear (make the unauthenticated come 
second).  Right now your authenticated /* overrides the unauthenticated 
completely, and thus you really have no such thing as an unauthenticated 
access.  Try making that one come first, then the unauthenticated becomes the 
exception.

Here is a great article on this issue and provides some good background to the 
problem you may be encountering:

http://www2.sys-con.com/ITSG/virtualcd/Java/archives/0704/mccay/index.html

In particular, and which applies to my statement above:

"Tomcat's implementation of the constraint-matching algorithm requires that the 
constraints appear within the deployment descriptor in the order of precedence 
required for the different types of URL patterns"


> Requests using Non-secure HTTP connections cannot access unsecured web 
> resources
> --------------------------------------------------------------------------------
>
>                 Key: GERONIMO-2695
>                 URL: https://issues.apache.org/jira/browse/GERONIMO-2695
>             Project: Geronimo
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: security, Tomcat, web
>    Affects Versions: 1.1.1
>         Environment: Geronimo running on Windows XP
>            Reporter: Aman Nanner
>         Attachments: test.war
>
>
> Consider the following fragment of my web.xml in my WAR:
> ----
>    <security-constraint>
>       <display-name>Unsecure Constraint</display-name>
>       <web-resource-collection>
>          <web-resource-name>Unsecure Resource Collection</web-resource-name>
>          <url-pattern>/common/error/*</url-pattern>
>          <url-pattern>/common/includes/*</url-pattern>
>          <url-pattern>/common/Message.jsp</url-pattern>
>          <url-pattern>/common/resources/*</url-pattern>
>          <url-pattern>/common/security/login.jsp</url-pattern>
>          <url-pattern>/common/security/logout.jsp</url-pattern>
>          <url-pattern>/servlet/branding/*</url-pattern>
>          <url-pattern>/servlet/image/*</url-pattern>
>          <url-pattern>/servlet/login/*</url-pattern>
>          <url-pattern>/servlet/definecookie</url-pattern>
>          <http-method>GET</http-method>
>          <http-method>POST</http-method>
>       </web-resource-collection>
>       <user-data-constraint>
>          <transport-guarantee>NONE</transport-guarantee>
>       </user-data-constraint>
>    </security-constraint>
>    <security-constraint>
>       <display-name>Secure Constraint</display-name>
>       <web-resource-collection>
>          <web-resource-name>Secure Resource Collection</web-resource-name>
>          <url-pattern>/</url-pattern>
>          <http-method>GET</http-method>
>          <http-method>POST</http-method>
>       </web-resource-collection>
>       <auth-constraint>
>          <role-name>MXSYSTEM</role-name>
>       </auth-constraint>
>       <user-data-constraint>
>          <transport-guarantee>NONE</transport-guarantee>
>       </user-data-constraint>
>    </security-constraint>
>    <login-config>
>       <auth-method>FORM</auth-method>
>       <form-login-config>
>          <form-login-page>/common/security/PreLogin.jsp</form-login-page>
>          <form-error-page>/common/security/error.jsp</form-error-page>
>       </form-login-config>
>    </login-config>
>    <security-role>
>       <description>Application System Role</description>
>       <role-name>MXSYSTEM</role-name>
>    </security-role>
> ----
> There are two sets of web resources defined: a secured web resource 
> collection, and an unsecured web resource collection.  The secured web 
> collection is by default everything that matches the "/" pattern.  In the 
> unsecured web collection, we use specific URL patterns so that certain 
> resources can be accessed prior to login.  Note that there is no security 
> role defined for the unsecured web resource collection, as these resources 
> should be available to every request.
> The problem is that access is denied to to the unsecured web resource 
> collection, even though they are defined as unsecured.  A blank HTML page is 
> returned instead of the appropriate resource.  After some debugging, I 
> discovered what seems to be a bug in the 
> org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm class.  Consider the 
> following code fragment in the hasResourceCollection(...) method:
> ----
>         // Which user principal have we already authenticated?
>         Principal principal = request.getUserPrincipal();
>         //If we have no principal, then we should use the default.
>         if (principal == null) {
>             return request.isSecure();
>         } else {
>             Subject currentCaller = ((JAASTomcatPrincipal) 
> principal).getSubject();
>             ContextManager.setCallers(currentCaller, currentCaller);
>         }
> ----
> When I make an HTTP connection to an unsecure web resource, I am 
> unauthenticated before I can login.  Thus, the principal in this case is 
> null.  In the case of a null principal, the code seems to base its 
> authorization on whether or not the request is secure!  This seems very 
> strange to me, as it should be able to accept normal, unauthenticated, HTTP 
> connections to unsecure web resources.
> I tried accessing the unsecured web resources over HTTPS, and sure enough, I 
> was able to access them because of the secure connection.  I'm not sure why 
> this works only over HTTPS...it should work in both cases.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to