You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by jfc <jf...@btopenworld.com> on 2002/08/28 16:11:51 UTC
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?
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 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.
jfc
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: does authorization occurr for each request?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 29 Aug 2002, jfc wrote:
> ok,
>
> I use tomcat4+jboss2.4.x, struts1.1 and tiles on jdk1.3.1_01 and suse
> linux kernel2.4.13.
>
> My MVC view has to be able to determine which whether or not a request
> belongs to any particular role in order to perform its rendering.
>
> It seems to me there are two preconditions to the container being able
> to return authentication and authorization info (auth info) when the
> application invokes any of the three programmatic security methods i.e.
> getRemoteUser, isUserInRole and getUserPrincipal.
>
> 1. Tomcat needs to be operating in default mode regarding caching of
> auth info.
>
> or
>
> 2. all requests need to be routed to secured resources which will
> enforce the container's re-retrieval of auth info. making it available
> via the methods mentioned above.
>
> To my mind, choosing precondition 2 (because caching is turned off)
> means that I would have to define multiple struts mappings for each and
> every piece of functionality based on role. e.g. if I have a
> '/do/greeting', I now have to have '/do/roleA/greeting', a
> '/do/roleB/greeting' etc. with /do/roleA/* declared as secure under
> roleA. I am concerned this will result in a bloated struts-config.xml
> and am not sure this is the way to go.
>
> So, to put it another way, I dont want to have to rely on this
> information having to be encoded in the URL because this translates to
> having the same action mapping duplicated for each role. Maybe I'm
> making it more difficult than it is and if so I ask you to bear with me
> a bit ;-)
>
> I accept what you say when you say I should be talking to the jboss guys
> but I would like confirmation that my solution lies in one of the two
> points mentioned above.
>
Unfortunately, I can give you no such assurance ... I don't have any clue
at all about what JBoss did in their integration of Tomcat, so I don't
know what other behavior might have changed. All I can
tell you is that Tomcat, in default mode, remembers authentication and
authorization information if you're using sessions.
A side effect of this is that the information is still valid when you
access an unsecured resource after logging on. This behavior is not
required by the servlet spec, and (from discussions in the Servlet 2.4
expert group) I am pretty sure that it's done differently by different
containers.
So, looking for a portable solution, something like what you're suggesting
(multiple mappings) sounds like it might work.
> Thanks for your time on this Craig. If I can get around the caching
> using point 2. then could you suggest a way to implement the action
> paths in struts or anotherway of doing it?
>
In the Struts-specific realm, the "roles" attribute on an action takes a
comma-delimited list of roles, and by default Struts implements an "OR"
test -- if the user has *any* of the listed roles, access is allowed. I
don't know if you can model your role names so that this helps, but it
might be feasible to just protect all of the action paths with a security
constraint on a role that every user is granted, and then use this list in
struts-config for finer-grained control over specific actions without
having to map them more than once.
If you needed an AND test instead, it would be easy to subclass the Struts
request processor and override the processRoles() method to achieve this.
> jfc
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: does authorization occurr for each request?
Posted by jfc <jf...@btopenworld.com>.
Craig R. McClanahan wrote:
>
>On Wed, 28 Aug 2002, jfc wrote:
>
>>Date: Wed, 28 Aug 2002 21:03:10 +0000
>>From: jfc <jf...@btopenworld.com>
>>Reply-To: Tomcat Users List <to...@jakarta.apache.org>
>>To: Tomcat Users List <to...@jakarta.apache.org>
>>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
>HttpSession.
>
>>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
>
>
>>Craig R. McClanahan wrote:
>>
>>>On Wed, 28 Aug 2002, jfc wrote:
>>>
>>>>Date: Wed, 28 Aug 2002 14:11:51 +0000
>>>>From: jfc <jf...@btopenworld.com>
>>>>Reply-To: Tomcat Users List <to...@jakarta.apache.org>
>>>>To: tomcat-user <to...@jakarta.apache.org>
>>>>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: <ma...@jakarta.apache.org>
>>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>>
>>>
>>
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
ok,
I use tomcat4+jboss2.4.x, struts1.1 and tiles on jdk1.3.1_01 and suse
linux kernel2.4.13.
My MVC view has to be able to determine which whether or not a request
belongs to any particular role in order to perform its rendering.
It seems to me there are two preconditions to the container being able
to return authentication and authorization info (auth info) when the
application invokes any of the three programmatic security methods i.e.
getRemoteUser, isUserInRole and getUserPrincipal.
1. Tomcat needs to be operating in default mode regarding caching of
auth info.
or
2. all requests need to be routed to secured resources which will
enforce the container's re-retrieval of auth info. making it available
via the methods mentioned above.
To my mind, choosing precondition 2 (because caching is turned off)
means that I would have to define multiple struts mappings for each and
every piece of functionality based on role. e.g. if I have a
'/do/greeting', I now have to have '/do/roleA/greeting', a
'/do/roleB/greeting' etc. with /do/roleA/* declared as secure under
roleA. I am concerned this will result in a bloated struts-config.xml
and am not sure this is the way to go.
So, to put it another way, I dont want to have to rely on this
information having to be encoded in the URL because this translates to
having the same action mapping duplicated for each role. Maybe I'm
making it more difficult than it is and if so I ask you to bear with me
a bit ;-)
I accept what you say when you say I should be talking to the jboss guys
but I would like confirmation that my solution lies in one of the two
points mentioned above.
Thanks for your time on this Craig. If I can get around the caching
using point 2. then could you suggest a way to implement the action
paths in struts or anotherway of doing it?
jfc
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: does authorization occurr for each request?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 28 Aug 2002, jfc wrote:
> Date: Wed, 28 Aug 2002 21:03:10 +0000
> From: jfc <jf...@btopenworld.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> 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
HttpSession.
> 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
>
> Craig R. McClanahan wrote:
>
> >
> >On Wed, 28 Aug 2002, jfc wrote:
> >
> >>Date: Wed, 28 Aug 2002 14:11:51 +0000
> >>From: jfc <jf...@btopenworld.com>
> >>Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> >>To: tomcat-user <to...@jakarta.apache.org>
> >>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: <ma...@jakarta.apache.org>
> >For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> >
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: does authorization occurr for each request?
Posted by jfc <jf...@btopenworld.com>.
Hi,
What kind of caching does the following tag disable?
<Valve className="org.apache.catalina.authenticator.FormAuthenticator"
debug="3" cache="false"/>
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.
Where does tomcat cache this info when caching is on and how can I
manually cache the info - and, again, what is the info (username and
password and roles or just roles?).
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)
thanks
jfc
Craig R. McClanahan wrote:
>
>On Wed, 28 Aug 2002, jfc wrote:
>
>>Date: Wed, 28 Aug 2002 14:11:51 +0000
>>From: jfc <jf...@btopenworld.com>
>>Reply-To: Tomcat Users List <to...@jakarta.apache.org>
>>To: tomcat-user <to...@jakarta.apache.org>
>>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: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: does authorization occurr for each request?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 28 Aug 2002, jfc wrote:
> Date: Wed, 28 Aug 2002 14:11:51 +0000
> From: jfc <jf...@btopenworld.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: tomcat-user <to...@jakarta.apache.org>
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>