[Esapi-user] Additional authenticators?

Kevin W. Wall kevin.w.wall at gmail.com
Fri Jan 8 18:10:50 EST 2010

Boberski, Michael [USA] wrote:
> Hi,
> I wouldn't guess there are any additional authenticators out there that
> people might consider contributing? LDAP, Kerberos, PKI? An LDAP
> authenticator reference implementation seems conspicuously absent.

I always rather figured that the 'reference' implementation for User and authN
and authZ was pretty much useless.  I think the hope was that at some point
someone from (say) Apache or Spring would write mechanisms that use the
ESAPI user administration and authN/authZ interfaces and integrate their
native methods. (E.g., the various Tomcat realms, etc.) In private emails
w/ Jim and/or Jeff I think there was some hope that teams working on Tomcat
or Spring, etc. would implement these. But they since they would need to
interact with their native components, they would need the Tomcat or Spring
or whatever jars.

One problem as I see it as the more stuff we do like this the more dependencies
we drag in with it. So if we wanted to integrate with Tomcat realms, we need
to pull in some Tomcat jars. For example, I have written LDAP authentication
using both the Mozilla LDAP SDK for Java and Sun's JNDI. Both used SSL to
do the bind. (The former requires the Mozilla ldapsdk.jar.) Both of them
were dirt simple...everything but the user ID was hard-coded into the class.
Certainly would not want to do that for an ESAPI reference implementation.
(Also, for an ESAPI reference implementation, probably the Sun JNDI approach
would be preferred as it doesn't require any additional jars.)  However,
each of these implementations did the LDAP bind (i.e., authentication) directly
over SSL/TLS. Since the time I've written the those (about 10 yrs ago), our
Directory Services team has changed the requirements for the way authN is done
for LDAP because the users are no longer necessarily under the same OU. So
now they require us to get a special "application" ID that is guaranteed to
be in a specific OU, authenticate as this ID using TLS, and then perform an
LDAP search to locate the DN of the user who we actually wish to authenticate.
We then finally use that DN to do an LDAP bind operation over TLS. That's
probably a lot more complicated that most businesses use (at least small to
medium ones) but my Directory Services team tells me its the recommended way
for large companies. Sooo... if we were to provide an LDAP reference
implementation, which model would we follow or would it have to be flexible
enough to handle any and all models. And were do we place those additional
properties defining things like the RDN, LDAP host name and port #, etc.?
Do they also go into the ESAPI.properties file? If so, do we need to update
the SecurityConfiguration interface and DefaultSecurityConfiguration class
to retrieve them. Sounds like scope creep to me.

However, if the point is to show users an approach to this via the ESAPI
documentation by _extending_ ESAPI beyond the reference implementation,
then I think that might not be a bad idea. Not sure it would make into into
the 2.0 docs, but after I finish up the crypto stuff, I can help you out on
that if you would like.

> I'll buy you a beer if you have a Kerberos one.

Well, since JDK 1.4, Sun has provided Kerberos classes based on the GSS-API
(RFC 2743) and the JAAS model. Sun has some example code in their Kerberos
JAAS tutorial...easily found by Googling. (You can email Sun the beer.)

Of course, if you want an example that uses Kerberos but is more appropriate
for the web (which is what most of ESAPI assumes), you might want to look
for a SPNego JAAS implementations that work with Kerberos, for example
one implementing RFC 4559. Searching for SPNegoLoginModule and Kerberos
turns up several, though I've not looked at any of them.

Kevin W. Wall
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME

More information about the Esapi-user mailing list