RE: [saml-dev] Looking for feedback on a first SAML implimentation.

["Scott Cantor" <cantor.2@osu.edu>]

> Thanks so much for the quick and detailed reply. Your suggestion that I
use
> an existing imlimentation has some appeal, however I'd prefer not to have
to
> run an entirely separate webapp just for sso, which seems to be what most
> existing implimentations are.

I would expect most Java implementations to be implemented as a filter, not
(entirely) a webapp. I don't implement in Java, my implementations for
Shibboleth run inside commodity web servers, but the comparable approach
would be a filter.

> Ideally, I'd like to use a java library inside our existing app.

I consider that a poor approach, as it ties your application to SAML. Your
application is on the web, and web servers already have a model for identity
and exposing information through CGI. Reimplementing that is a mistake in
most cases.

Point being, SAML is the web server's business, not your application's.
Tying yourself to SAML is just as wrong as tying yourself to OpenID or
anything else. Don't make that mistake. Leave that to the deployer, even if
you're the deployer. Eventually you'll need to support something else, you
can bank on it.

> I thought OpenSAML might fit my needs, but it obviously
> isn't foolproof enough as it's what I used to generate the flawed SAML I
> pasted in my original post!

OpenSAML is a low-level toolkit. It doesn't give you a profile
implementation, it gives you the libraries to write a profile
implementation. (Shibboleth is an example of a profile implementation, as
are others written with or without OpenSAML.) As a toolkit, it requires that
you know exactly what you want to do, and have a working knowledge of XML,
SAML, PKI, and other technologies. It will not hold your hand, and it will
hurt you very badly if you don't have that knowledge.

There are also some higher level libraries from other sources written on top
of it and they're linked from the web site.

> 1) Am I right in my assumption that the "existing implimentations" that
you
> refer to will tend to be standalone webapps rather than libraries?

No. A stand-alone web app by definition cannot provide SSO to another web
app. Something in the second web app has to be consuming the information
produced by the first one.

What you will find are people who glue SAML to something that's not SAML.
The SAML piece is often a web app and the non-SAML piece is relatively
hidden and undocumented, but it has to be linked on some level to the
eventual application, whether via API or filter. That doesn't make the
solution as a whole a standalone thing.
 
> 2) Do you know of a java library that will "hold my hand" a bit more than
> OpenSAML?

There's a Java package that was done on top of OpenSAML that I believe is
intended to be higher level. There are also complete implementations on top
of it like the one the Danish govt wrote. There's Sun's OpenSSO. Lots of
others around I imagine.

> Thanks for helping me wrap my head around this stuff! I've looked at
dozens
> of SAML-related web sites and tutorials, poured over the SAML
documentation,
> but am still having a bit of trouble figuring out how this is all supposed
> to work.

My advice is to do less coding and more integration, and design the
application to be agnostic to the form of authentication, something that is
learned through experience but isn't something the material on SAML is going
to explain.

-- Scott