Re: [securityfilter-user] Security Filter and Tomcat 7

[Christopher S. <ch...@ch...>]

Matthew,

On 12/13/11 5:54 PM, Matthew Hixson wrote:
> Hi Chris, I'm finally getting back to trying to make our app run with Tomcat 7.

Sorry, I only now noticed this message. This mailing list doesn't get a
great amount of traffic :(

> Isn't this a change that should be made to security filter so that it
> runs correctly with Tomcat 7?  I'd be willing to bet that other
> people have and will continue to run into this problem.
>
> I had written my own Realm implementation and this worked just
> great, however my current exception doesn't even look like execution
> reaches my realm class.
> 
> Dec 13 14:03:44 SEVERE thr:13 u:- c:org.apache.jsp.e_jsp m:_jspService java.lang.NoSuchMethodError: org.apache.catalina.Realm.hasRole(Ljava/security/Principal;Ljava/lang/String;)Z
> at org.securityfilter.realm.catalina.CatalinaRealmAdapter.isUserInRole(CatalinaRealmAdapter.java:108)
> at org.securityfilter.filter.SecurityFilter.doFilter(SecurityFilter.java:214)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)

Yeah, the problem is that the CatalinaRealmAdapter class is built
against a quite-old version of Tomcat's "Realm" class.

A while back, when I upgraded to a newer version of Tomcat (5.5? 6.0?) I
just bit the bullet and wrote my own Realm from scratch (in fact,
stealing a lot of Tomcat's DataSourceRealm code).

Tomcat's Realms are much more difficult to work with, now. They used to
be fairly lightweight and not have too many hooks back into their own
non-public API (that is to say, the part of the API that should be stable).

Now, you basically have to hook-into their own internals so that things
like logging and, etc. work without throwing NPEs and stuff like this.
This is another one of those cases: you have to provide a "Wrapper"
object to the Realm.hasRole method in order for it to work, and that
requires reaching into Tomcat's internals to get an object that
represents the current webapp.

That's not a trivial thing to so, especially when there's a bunch of
different versions out there that all need to work. It's worse to break
backward-compatibility IMO than it is to fail to support a new version
moving forward: you don't want to surprise people who don't know
something's changing.
> My realm is defined in security-filter.xml as:
> 
> <realm className="com.company.authentication.MyRealm">

Presumably, this class extends CatalinaRealmAdapter or is wrapped-up in
CatalinaRealmAdapter? How are you doing that, exactly?

You have a few options right now:

1. Bail on CatalinaRealmAdapter and write your own Realm (or I can give
   you my DataSourceRealm if you want it).

2. Override the isUserInRole in MyRealm and figure out how to get
   the proper parameter to Tomcat's Realm interface.

3. Help me work out a solution that can be used across multiple versions
   of Tomcat.

Honestly, the usefulness of this project was significantly diminished
when Oracle published Servlet 3.0 because securityfilter's primary job
in the real world was to allow webapps to accept logins without first
requiring the user to request a protected resource (and it took long
enough... thanks Sun/Oracle). Yes, other things have been built-into sf
as well ("remember me", parameter-forwarding, etc.) but all that stuff
can be provided by filters that are orthogonal to actual authentication
and authorization.

I don't see a great future for sf, other than continuing to exist in its
current form. I once had aspirations of re-writing the entire thing in a
more modular way (have you seen some of the code in there?) but I kept
coming back to the same question: does anyone really need sf anymore? I
don't want to spend a bunch of time on it if it's slowly going to die. I
still use it on all my own projects because it has features that would
be difficult to get into containers (such as forwarding certain request
parameters after the authentication stage to the next resource that is
requested, or being able to get the IP address of the request for
logging authentication failures). I do use my own heavily-customized
realm (that extends the DataSourceRealm I sometimes give-out to users of
sf) but that could be re-written as a subclass of Tomcat's
DataSourceRealm if I didn't need sf for anything else.

Anyhow, I'm open to any thoughts you might have about, well, anything :)

Thanks,
-chris