Configuring a custom Authenticator

2003-02-14 Thread Bryan Field-Elliot
I'm looking at the code for BaseAuthenticator and FormAuthenticator as a
basis for building my own.

It's not clear from the Javadocs where I configure Tomcat to use this
Valve...

1. Do I configure it by declaring a Valve element in server.xml, or is
there a special (undocumented) Authenticator element?

2. Do the other styles of Authenticator (such as FormAuthenticator)
still work, if I install my own custom Authenticator as well?

3. Am I mucking around with web.xml's auth-method element too, adding
my own custom type in addition to BASIC, DIGEST, FORM, and CLIENT-CERT?
If I'm not, then, which of the preceeding am I to configure in that
space?

Thanks,
Bryan









Re: Configuring a custom Authenticator

2003-02-14 Thread Craig R. McClanahan


On Fri, 14 Feb 2003, Bryan Field-Elliot wrote:

 Date: 14 Feb 2003 17:21:30 -0700
 From: Bryan Field-Elliot [EMAIL PROTECTED]
 Reply-To: Tomcat Users List [EMAIL PROTECTED]
 To: Tomcat Users List [EMAIL PROTECTED]
 Subject: Configuring a custom Authenticator

 I'm looking at the code for BaseAuthenticator and FormAuthenticator as a
 basis for building my own.

 It's not clear from the Javadocs where I configure Tomcat to use this
 Valve...

 1. Do I configure it by declaring a Valve element in server.xml, or is
 there a special (undocumented) Authenticator element?


The former ... an Authenticator *is* a Valve, so you can use a Valve
element to configure one.

 2. Do the other styles of Authenticator (such as FormAuthenticator)
 still work, if I install my own custom Authenticator as well?


At startup time, Tomcat will add an Authenticator (of a type determined by
the login-method in web.xml.  This Valve is added in to the pipeline
*after* any valves you've explicitly loaded in server.xml.

Your secret weapon is that all the standard Authenticator valves have
logic like this at the beginning of their authenticate() methods:

// Have we already authenticated someone?
Principal principal = hreq.getUserPrincipal();
if (principal != null) {
... set up some stuff for single sign on if needed ...
return (true); // Authentication successful
}

So, if any Valve that executes prior to this in the pipeline stores a
Principal in the request, the standard authentication will be skipped.

IIRC, this technique is also leveraged, for example, when you use Apache
in front of Tomcat and configure Apache to do the authentication -- the
fact that this is done will get carried through the web connector and will
have the effect of bypassing the Tomcat-level authentication process.

 3. Am I mucking around with web.xml's auth-method element too, adding
 my own custom type in addition to BASIC, DIGEST, FORM, and CLIENT-CERT?
 If I'm not, then, which of the preceeding am I to configure in that
 space?

That would be another way to set things up -- you would need to modify the
resource file Authenticators.properties in package
org.apache.catalina.startup to reflect the class name of your custom
authenticator.

This technique can be useful if you want *all* authentication (for this
webapp) to happen through the custom authenticator.  If you want your
custom stuff to apply to only certain requests, and use one of the
standard mechanisms for the rest, manually configuring a Valve is your
best bet.


 Thanks,
 Bryan

Craig


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]