[Esapi-user] Exploring ESAPI identity management

Boberski, Michael [USA] boberski_michael at bah.com
Wed Jan 20 15:34:18 EST 2010

Got it, that "ESAPI was designed [specifically] to help out with username/password authentication  since that was like 90% of the market", that was something that I did not know, I thought it was intended to be more generic.

Ok, so for example, developing LDAP reference code, simple cert-auth based reference code, those kinds of things the current ESAPI user authentication code can handle OK.

But, for other technologies (identity 2.0, SSO, or otherwise), some rethink may ("may", i.e., not for certain, simply based on this thread) be needed.

Thanks for your guys' help. These are questions I think I'm not alone in having.

Mike B.

-----Original Message-----
From: Jeff Williams [mailto:jeff.williams at aspectsecurity.com] 
Sent: Wednesday, January 20, 2010 3:25 PM
To: Boberski, Michael [USA]; Kevin W. Wall
Cc: ESAPI-Users
Subject: RE: [Esapi-user] Exploring ESAPI identity management

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.


-----Original Message-----
From: Boberski, Michael [USA] [mailto:boberski_michael at bah.com]
Sent: Wednesday, January 20, 2010 3:14 PM
To: Kevin W. Wall; Jeff Williams
Cc: ESAPI-Users
Subject: RE: [Esapi-user] Exploring ESAPI identity management

Kevin, thank you for responding as well.

What I'm driving at is to clarify how ESAPI might help when it comes to its user and authentication controls specifically in more than very simple configurations.

And, to clarify existing descriptions, all of this towards the end of further refining them in design specs, in anticipation of developing TCKs.

One thing it sounds like we're in agreement on is that the use of "identity management" in the ESAPI book is not correct, since it is a loaded term more generally.

And, it also sounds like, the existing user and authentication interfaces could most probably be used as-is to support "identity 2.0"
solutions, perhaps suggesting the addition of a couple of more authentication reference implementations on the to-do list.

Am I understanding you guys correctly, am I coming to the same/correct conclusions?

Mike B.

-----Original Message-----
From: Kevin W. Wall [mailto:kevin.w.wall at gmail.com]
Sent: Wednesday, January 20, 2010 3:02 PM
To: Jeff Williams
Cc: Boberski, Michael [USA]; ESAPI-Users
Subject: Re: [Esapi-user] Exploring ESAPI identity management

Jeff Williams wrote:

> I got a bit confused by the writeup, but I think you're working out 
> how to use ESAPI to achieve SSO, right?

That was my take on it.

> That's a bit different than identity management, at least to me.

They are related in that almost every IAM system offers SSO, but yes, they are different...at least from where I sit.

> Anyway, it'requireds a very useful
> discussion since so many sites are really conglomerations of 
> applications these days.  Rather than create yet another cookie-based 
> SSO approach, I'd really like to see us head towards a SAML, OpenID, 
> or other Identity 2.0 type solution.

I've been involved with RSA ClearTrust (now called "Access Manager") for almost 7 years and before that, worked on a proprietary WAM product.
Each are used for authN/SSO than for any other reason. (Only perhaps 10-15% of the use is for authZ and even then, it's very course-grained.)

I also have spent the past 2 years looking extensively at federation and SSO, especially those solutions based on SAML. I've only briefly looked at OpenID, and that was when a security issue came up with something in the OpenID spec/protocol last fall or so.

What I will tell you right off the bat is that all SAML implementations seem to be inherently complicated (at least for SAML 2.0) and I wholly anticipate troubleshooting issues when SAML doesn't work to be a major pain in the @rse.

However, as we were evaluating SAML vendors, I did run across one lightweight federation SSO specification that I was fairly impressed with. It is an
(expired) draft RFC.  The spec is called Open Token and it was created by some folks at Ping Identity.

Also, if I'm not mistaken, I think that the Ping Identity folks have a Java implementation of Open Token available as a free download on their web site and that it is offered under LGPL2. (Of course, someone should verify
that.) I do think you are supposed to register w/ them before downloading though.

But Open Token is what you might think of as SAML-lite. It is not XML based and usually is sent via cookie, but it can also be sent as hidden form variable or query parameter. The spec also has a provision for preventing replay attacks.

However, my point is, even if it is not something that already has a FOSS toolkit available, the spec is really pretty simple to implement.

Besides there are already plenty of SAML implementations (OpenSAML, Shibboleth, CAS, etc.) that I'm not certain the world needs any others.

Anyhow, I'd encourage you to take a look at Open Token as a possible authN approach for federated SSO to be used by ESAPI.

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