[Esapi-user] Exploring ESAPI identity management

Kevin W. Wall kevin.w.wall at gmail.com
Wed Jan 20 15:53:22 EST 2010

Jeff Williams wrote:
> Ideally, I think that the programmer shouldn't have to do anything
> special to deal with authentication and session management in an SSO
> environment. That may mean that there needs to be some [plugin] work to
> deal with SSO providers, but that's it.  Hopefully that won't mean API
> changes, but I suspect it will.  ESAPI was designed to help out with
> username/password authentication since that was like 90% of the market.
> But perhaps it's time to help organizations get past that.

About 12 yrs ago when I started contracting at my present job, I designed
and implemented a proprietary WAM with a small team where the WAM supported
multiple authN types. IIRC, the key was getting the right level of abstraction.
We defined a Claimant class to carry the uncorroborated identity of a user
prior to authentication and a Credentials interface or abstract class to
represent things you would do with a credential.  Then I implemented concrete
classes that extended Credentials in classes like LDAPCredentials (for
authentication using LDAP password using LDAP bind operation over SSL),
X509Credentials (for X.509 certs), SecurIDCredentials for RSA SecurID, etc.
The concrete credentials class essentially acted as a proxy pattern and each
of them carried code to authenticate as appropriate. Then the Authenticator
just invoked a Credentials.authenticate() method on the Credential object
that it was passed.

So I don't think you have to go very far to extend it. Just replace places
where you have
	String password
	Credentials cred
(or Credentials[] creds		if you wish to support multi-factor authN)
and implement the various Credentials class). BTW, I claim none of this is
new. I came up with it after studying GSS-API. It was very similar.

HTH w/ some ideas of how to proceed.

NOTE: On the downside, it does make it somewhat more of a pain for those only
      using username/password for authN.
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