OpenSAML user discussion

[Scott Cantor <>]

> I concluded that the best basis for a toolkit in Java was 
> OpenSAML, but my customers need Liberty alliance features so
> I must have some clues for the delta between SAML 
> specifications & Liberty features in order to be
> able to make a planning for coding these faetures using 
> opensaml as a low layer.

Hmm, it's not a small delta, and frankly, the value add you really get from
building a Liberty implementation on top of this code is arguably pretty
small. You could save time and steal a lot of the signing code, but probably
little else.

Liberty today purports to "extend" SAML 1.1, but that's a fiction. It's a
do-over that doesn't extend so much as "inspire itself" from the original
SAML draft specs and uses a few SAML objects here and there. The schema
extensions in particular get pretty invasive, and it's far from clear to me
that you could implement ID-FF by extending my classes without a lot of
work.

Also, the really interesting bits (PKI for example) are all in the
Shibboleth layer we built on top of the SAML code.

I'm not trying to discourage you, just want you to know what you're looking
at.

> I'm very confused by some slides fetched on sourceid website where
> liberty is shown as a layer above saml but where some saml 
> features are not present in the liberty protocol

I wouldn't characterize ID-FF as a layer on SAML, more like a big ball that
has a bit of SAML inside it.

The good news is that SAML 2.0 is a merge of SAML and ID-FF into one unified
spec that I think is pretty well designed (my bias showing since I helped
design it). The bad news is the spec is only just now nearing final drafts
and it will be a while before we get it implemented. Depending on your time
frame though, I would be thinking hard about it.

-- Scott