tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: does authorization occurr for each request?
Date Wed, 28 Aug 2002 19:57:40 GMT

On Wed, 28 Aug 2002, jfc wrote:

> Date: Wed, 28 Aug 2002 21:03:10 +0000
> From: jfc <>
> Reply-To: Tomcat Users List <>
> To: Tomcat Users List <>
> Subject: Re: does authorization occurr for each request?
> Hi,
> What kind of caching does the following tag disable?
>  <Valve className="org.apache.catalina.authenticator.FormAuthenticator"
>      debug="3" cache="false"/>

If you are using sessions, Tomcat normally caches the looked-up Principal
object in the session so that it doesn't need to be looked up on every
request.  Setting the "cache" property to false disables this.

> According to Scott Stark from jboss, caching is turned off within the
> jboss/tomcat bundle with the above tag. And this is the default as there
> are conflicts with the propagation to the ejb layer). How does this
> affect the web container's ability to recognize a previously
> authenticated request on a subsequent request to a non-secured resource
> (within the same session). It appears as though tomcat won't hold the
> info neccessary to authorize the request.

You'll have to ask the JBoss folks how they deal with this issue, since
they are modifying Tomcat's default behavior.

> Where does tomcat cache this info when caching is on

In private variables associated with the internal object that implements

> and how can I
> manually cache the info

You can't access this stuff from a webapp; the only thing you can do is
set or not set the "cache" property.

 - and, again, what is the info (username and
> password and roles or just roles?).

The standard Authenticator caches the Principal object returned by the
Realm.  In the case of Tomcat's standard Realm implementations, this is an
org.apache.catalina.realm.GenericPrincipal that stores the username and
all the roles.  I haven't got a clue what JBoss's Realm might return.

> I'm trying to establish whether I need to secure every single requested
> resource in order to get the web container to 'remember' the session's
> authentication or whether by doing some kind of caching myself, I can
> effectively replace this particular caching of tomcat's (which is turned
> off by default in the jboss/tomcat bundles)

You really need to be asking the JBoss folks these questions, since their
integration changes the behavior of some of Tomcat's standard components,
and replaces others.  But I don't really understand why you care about the
internal implementation details in the first place -- as long as the
combined Tomcat+JBoss server acts in a spec-compliant manner with regards
to security, isn't that enough?

> thanks
> jfc


> Craig R. McClanahan wrote:
> >
> >On Wed, 28 Aug 2002, jfc wrote:
> >
> >>Date: Wed, 28 Aug 2002 14:11:51 +0000
> >>From: jfc <>
> >>Reply-To: Tomcat Users List <>
> >>To: tomcat-user <>
> >>Subject: does authorization occurr for each request?
> >>
> >>Hi,
> >>
> >>A question re declarative security and form-based authentication and
> >>subsequent request authorization:
> >>
> >>Can anyone confirm whether or not authorization(i.e. role checking) is
> >>repeated for each request(to a secured resource) after a user has been
> >>authenticated?
> >>
> >
> >Yes, it is.  The URL from each request is matched against the security
> >constraints you have defined, and the specified role restrictions are
> >enforced on every request.
> >
> >>There would be times when a subsequent request comes in to a resource
> >>secured under a role which is higher or lower within the applications
> >>user hierarchy and I need to know what behaviour tomcat implements.
> >>
> >
> >Tomcat doesn't know anything about "higher" or "lower" roles.  It only
> >asks whether a user has one of the roles listed in the security
> >constraint.
> >
> >>Tomcat will surely have a list of valid roles for a particular
> >>authenticated user right? This would make sense as a check can be
> >>performed as and when required to determine whether or not the user has
> >>been assigned the required role.
> >>
> >
> >In the default Realm implementations, the list of roles assigned to a user
> >is cached in the Principal object that resulted from authentication, so
> >the role checking is an in-memory lookup in a HashMap.  However, it's
> >perfectly reasonable to implement a Realm that goes to a database (or some
> >other external source of information) every time -- especially useful in
> >scenarios where the set of roles might be changing (such as a role that
> >says "can use this URL from 8am to 5pm on weekdays").
> >
> >>jfc
> >>
> >
> >Craig
> >
> >
> >--
> >To unsubscribe, e-mail:   <>
> >For additional commands, e-mail: <>
> >
> >
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message