[Esapi-user] Exploring ESAPI identity management

Jeff Williams jeff.williams at aspectsecurity.com
Wed Jan 20 15:24:52 EST 2010


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.

--Jeff


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

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