tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Request not forwarded to login page with security-constraint after session time-out
Date Fri, 27 Feb 2009 16:50:51 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chuck,

On 2/26/2009 7:22 PM, Caldarale, Charles R wrote:
>> From: Mark Thomas [mailto:markt@apache.org]
>> Subject: Re: Request not forwarded to login page with
>> security-constraint after session time-out
> 
>>> What the spec is not explicit about is the combination
>>> of "*" with an empty or non-existant <security-role> list.
> 
>> I think it is quite clear. It means no-one gets access.
> 
> We'll have to agree to disagree; I find it ambiguous, and obviously
> others have different interpretations, so it definitely isn't clear. I'd
> like to see the spec document how authentication can be configured when
> no authorization (and therefore no roles) is necessary.

I don't find this ambiguous at all (this is the XSD documentation for
auth-constraintType).

"
The auth-constraintType indicates the user roles that
should be permitted access to this resource
collection. The role-name used here must either correspond
to the role-name of one of the security-role elements
defined for this web application, or be the specially
reserved role-name "*" that is a compact syntax for
indicating all roles in the web application. If both "*"
and rolenames appear, the container interprets this as all
roles.  If no roles are defined, no user is allowed access
to the portion of the web application described by the
containing security-constraint.  The container matches
role names case sensitively when determining access.
"

No roles listed? Nobody gets access. * = all (should be "any") roles
defined in the application. No roles defined? Nobody gets access.

As I said, practically speaking, this last constraint hasn't been
properly enforced in many versions of Tomcat (or securityfilter! we're
working on fixing that somehow).

>> Chuck and I are off on our own little tangent.
> 
> Not sure that's entirely true, since the OP's situation
> (authentication without need for authorization) doesn't seem to be
> covered by the spec, and behavior of other containers (and even
> different versions of Tomcat) may well differ from what he's getting today.

I agree with Chuck. Although the OP's issue was resolved (login pages
rarely look like JSON responses... oops!), the fact that the OP was
abusing the authentication and authorization mechanism of Tomcat is not
good. I'm not sure why any user was ever properly authorized, here: a
SQLException in role gathering results in successful authorization for
all users? Shouldn't the default be to disallow access unless
authorization is successful? Sounds like a horrible security bug to me.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmoGesACgkQ9CaO5/Lv0PCK3wCbBVtSKKYyJzxnqDtpLoizTv4D
8moAn1XjL2qRTjgEplLyJ5Jha5Pd6Bu7
=dhaL
-----END PGP SIGNATURE-----

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


Mime
View raw message