tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 44529] New: RealmBase authorization via hasResourcePermission not fully servlet spec compliant
Date Tue, 04 Mar 2008 16:04:54 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=44529

           Summary: RealmBase authorization via hasResourcePermission not
                    fully servlet spec compliant
           Product: Tomcat 6
           Version: 6.0.14
          Platform: PC
        OS/Version: Windows Vista
            Status: NEW
          Severity: minor
          Priority: P2
         Component: Servlet & JSP API
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: robertjanwesterhof@gmail.com


The authorization implementation in RealmBase, in the hasResourcePermission
method is not fully servlet specification compliant. The spec (both 2.4 and
2.5) states:

"...
A security constraint that does not contain an authorization constraint shall
combine with authorization constraints that name or imply roles to allow
unauthenticated access. 
The special case of an authorization constraint that names no roles shall
combine with any other constraints to override their affects and cause access
to be precluded.
..."

In Tomcat this works fine as long as there aren't weird (but legal!)
combinations or security-constraints on the same URLs.

Example:

  <security-constraint>
    <web-resource-collection>
      <url-pattern>/someUrl/*</url-pattern>
      <http-method>POST</http-method>
    </web-resource-collection>
    <!-- no auth-constraint, to allow everyone -->
  </security-constraint>

  <security-constraint>
    <web-resource-collection>
      <url-pattern>/someUrl/*</url-pattern>
      <http-method>POST</http-method>
    </web-resource-collection>
    <!-- no roles, to allow noone -->
    <auth-constraint />
  </security-constraint>

(if we ignore that this kind of configuration is pretty pointless,)
the spec dictates that a POST to /someUrl/index.html should be denied access.
Tomcat grants it. (both 5.5.23 and 6.0.14 do)


Example 2:

  <security-constraint>
    <web-resource-collection>
      <url-pattern>/someUrl/*</url-pattern>
      <http-method>POST</http-method>
    </web-resource-collection>
    <!-- no roles, to allow noone -->
    <auth-constraint />
  </security-constraint>

  <security-constraint>
    <web-resource-collection>
      <url-pattern>/someUrl/*</url-pattern>
      <http-method>POST</http-method>
    </web-resource-collection>
    <auth-constraint>
      <role-name>*</role-name>
    </auth-constraint>
  </security-constraint>

Now it gets interesting. In "strict" mode, access to /someUrl/index.html is
denied (regardless of the web.xml-configured security roles and the roles the
user has).
In "auth-only" mode, access is always granted, and in "strict auth-only" mode
access is granted if there are no web.xml-configured security roles.
Now these modes are a Tomcat addition to the spec, but I feel access should
have been denied in all modes, both to stay in line with the spec and to keep
the behaviour predictable.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message