[Esapi-user] Additional authenticators?
mike.boberski at gmail.com
Fri Jan 8 18:57:53 EST 2010
Kevin, thanks, I will research based on this.
Any idea about the c#, is the lack of user/authenticator by design or
no, eg assuming no one would use it given IIS etc?
On 1/8/10, Kevin W. Wall <kevin.w.wall at gmail.com> wrote:
> Boberski, Michael [USA] wrote:
>> 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
> 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
> 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)
> 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
> 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
> 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
> Esapi-user mailing list
> Esapi-user at lists.owasp.org
More information about the Esapi-user