tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Potter <...@coas.oregonstate.edu>
Subject Authentication Granularity Question
Date Sat, 30 Sep 2006 00:50:57 GMT



Greetings -

I have a question about the granularity of authentication within  
Tomcat 5.x. I have read the Tomcat 5 docs, the Java Servlet  
Specification version 2.4, and done some looking through the email  
archives. Hopefully this topic hasn't already been beat to death.

I would like to be able to specify different authentication rules for  
different url patterns within my web application. For example in my  
web.xml file I might have:

     <security-constraint>
         <web-resource-collection>
             <web-resource-name>fnoc1</web-resource-name>
             <url-pattern>/s4/nc/fnoc1.txt</url-pattern>
         </web-resource-collection>
         <auth-constraint>
             <role-name>fn1</role-name>
         </auth-constraint>
     </security-constraint>

     <security-constraint>
         <web-resource-collection>
             <web-resource-name>fnoc2</web-resource-name>
             <url-pattern>/s4/nc/fnoc2.txt</url-pattern>
         </web-resource-collection>
         <auth-constraint>
             <role-name>fn2</role-name>
         </auth-constraint>
     </security-constraint>

     <login-config>
         <auth-method>BASIC</auth-method>
         <realm-name>MyApplicationRealm</realm-name>
     </login-config>

Where the the security roles fn1 and fn2 have no common members.


The complete URIs would be:

    http://localhost:8080/mycontext/s4/nc/fnoc1.txt
    http://localhost:8080/mycontext/s4/nc/fnoc2.txt


Now - this works, for clients that aren't to smart - i.e. they don't  
cache anything.


However, if I try with a browser, once I authenticate for one URI,  
then I am locked out of the other one until I successfully "reset"  
the browser (purge all caches).

I think the reason is as follows:

In the exchange between Tomcat and the client, Tomcat is sending the  
header:

    WWW-Authenticate: Basic realm="MyApplicationRealm"

And the client authenticates. When the second URI is accessed Tomcat  
sends the the same authentication challenge, with the same WWW- 
Authenticate header. The client, having recently authenticated to  
this realm, resends the authentication information, and, since it's  
not valid for that url pattern, the request is denied.


My questions:

- Is that it? Or is there a way that I can get Tomcat to give me  
finer authentication granularity than this?

In my reading of the Servlet Specification I didn't see that a  
particular webapp couldn't associate multiple authentication realms  
with multiple url-patterns. But it seems that's what is happening: In  
the Tomcat world a webapp appears to be a synonym for a single  
authentication realm, as expressed in the HTTP header "WWW- 
Authenticate".


- Is the only way that I can get finer granularity to handle the  
authentication in my webapp or in a custom javax.servlet.Filter?


- In my example I used BASIC authentication. Does this problem  
persistent for DIGEST and FORM?



Thanks in advance for your time and input,


Nathan





========================================================
Nathan Potter              Oregon State University, COAS


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message