tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Burch <>
Subject Re: Custom realm.authenticate() that would work with any realm - possible?
Date Fri, 09 Dec 2011 09:39:29 GMT
On 09/12/11 18:02, wrote:
> Hi Chuck,
> Thanks for the pointer to the CombinedRealm, but, as I've been working with the test
implementation that I mentioned for extending the JNDIRealm, I *think* that I'm coming to
the realization that I was asking for is probably not possible, or at least not practical,
unless I'm totally missing something.
> The reason I'm thinking this is that, for example, in the case where I'm extending the
JNDIRealm, in my custom JNDIRealm, I've had to make calls to the super.setXXXX() methods to
set parameters in the JNDIRealm class that I'm extending, in order for the calls that I then
make to the super class (e.g., super.getUser()) to work.
> Again, I may be missing something, or doing things completely wrong, but if not, then
that means that if I was going to try go design my realm extender to support all of the normal
realm types, my code would get fairly complex, because it'd have to "know" all of the parameters
for all of the different realm types, in order to set the parameters in the super class. 
It was messy enough doing that for just one realm type (JNDIRealm), and for just calling two
methods in the super JNDIRealm class, but I imagine if I was trying to extend 5 or 6 realm
types, all in one piece of code, it'd be a real mess.
> Anyway, if anyone has some insight into doing something like this, please post back.
> Otherwise, I think the best approach is to implement one realm extension for each of
the normal Tomcat realms that we'll want to be able to support.
> Thanks again,
> Jim

I have come to this thread rather late in the day and I don't want to 
confuse the situation... take my comment, if it is relevant, with 
caution. If it isn't relevant, don't let me spiral it off-topic.

The servlet 3.0 spec allows for "vendor specific" <Login-config> 
<auth-method> values, e.g. tomcat uses "NONE" for containers that have 
not defined a <login-config> section.

The standard login methods (FORM, BASIC, etc) are implemented as 
concrete classes that extend 
org.apache.catalina.authenticator.AuthenticatorBase (e.g. 
FormAuthenticator, BasicAuthenticator, etc).

Have you considered writing a "vendor specific" NoPasswordAuthenticator 
class to do what you need? It needs to contain little more than an 
authenticate method that will be called by all appropriate code.

I have just submitted a suggested fix to NonLoginAuthenticator 
( which shows 
how to inject an existing Principal instance into a SingleSignOn 
session. This might give you some idea how to achieve what you want 
without the complexity of subclassing all the standard realms.



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

View raw message