[Esapi-user] Exploring ESAPI identity management

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


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?

Best,
 
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.
(http://tools.ietf.org/html/draft-smith-opentoken-02)

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
--
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