On Oct 9, 2006, at 11:20 AM, Christopher Schultz wrote:
Nathan,
I am using Tomcat 5.5. I would like to be able to specify different
authentication rules for different url patterns within my web
application.
[snip]
However, if I try it 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).
Its probably because you are deleting the cookie associated with
the login.
When Tomcat does its authentication, it sends a cookie to your browser
with the path "/mycontext", and nothing else. Once you have
authenticated once, Tomcat assumes that you have all the
authentication
information you will ever need. So, once you hit this URL:
http://localhost:8080/mycontext/s4/nc/fnoc1.txt
You will have an auth token associated with your session that says
that
you are in the "fnoc1" role.
If you then hit this URL:
http://localhost:8080/mycontext/s4/nc/fnoc2.txt
Tomcat will check your (existing) authentication information to see if
you are in the fnoc2 role. If you are, you are allowed access. If not,
you get the "forbidden" message. Tomcat will /not/ ask you to
re-authenticate when you do not have the proper credentials. Tomcat
/only/ asks for auth info when you don't have /any/ credentials.
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-name, resends the authentication information, and,
since it's
not valid for that url pattern, the request is denied.
This is exactly correct.
- Is that why the browsers are locking out the one URL after the
other
has been authenticated?
See above. It's because of the "path" attribute of the Cookie that
Tomcat uses to track your session. Credentials are related to (but not
stored in) your session. Since your session already says you are
"fnoc1"
(but apparently not "fnoc2"), you are simply denied access.
- Is there a way that I can get Tomcat to give me finer
authentication
granularity than this?
I believe you would have to re-write the mechanism that deals with
authentication. Sound like a great add-on!
We'll see. If I get pointed in that direction I may be able to
contribute something.
- 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. It seems that 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 that true?
The servlet spec is woefully silent on all matters related to
authentication. It basically says "the container can provide an
authentication mechanism", but then leaves everything else wide
open. :(
- Is the only way that I can get finer granularity to handle the
authentication in my webapp or in a custom javax.servlet.Filter?
Perhaps.
One question: if you a user who needs access to both resources, why
are
they not associated with both roles? That's the general was to do
authorization. You authenticate /once/ and then authorization is
performed for each request. Your users ought to be associated with the
proper roles in order to give them access to everything they need. You
wouldn't give out different username/password pairs for each resource,
right? No, you generally give each user a username/password pair and
then give them access to the appropriate resources. So, in this case,
why isn't it working for you?
Well... To be honest we are still in the process of developing use
cases for our user authentication. It may well be that we can make
the current Tomcat scheme work for us, once we have a clearer idea of
what our users require. In the mean time I was experimenting with
Tomcat and I had questions about the results. I want to be able to
accurately represent what we can and cannot achieve using Tomcat's
existing security arrangements.
Thanks so much for your helpful reply!
Nathan
- I have only experimented with BASIC authentication. Do DIGEST
and FORM
based authentication allow for different behavior w.r.t. the
<realm-name> attribute in the <login-confg>?
The different types of authentication don't really change any of this.
The last time I checked (long ago, I might add), DIGEST authentication
wasn't all that standard when it came to various browsers, so you
might
want to avoid that headache.
-chris
========================================================
Nathan Potter Oregon State University, COAS
[EMAIL PROTECTED] 104 Ocean. Admin. Bldg.
541 737 2293 voice Corvallis, OR 97331-5503
541 737 2064 fax
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
