On 12/1/06, Legido Mart璯ez, Isidoro <> wrote:
>
> So, In the first level we have the vocabulary, the pure XML schema. We can
> find here SAML 1.1, SAML 2.0, Liberty, Shibboleth(?)....
As a specification, Shibboleth is a very thin layer on top of SAML
V1.1. Basically, Shibboleth adds SP-initiated flows to the SAML V1.1
browser profiles, and that is all. In particular, it doesn't add much
in the way of schema.
Liberty ID-FF, on the other hand, layers a significant XML schema on
top of SAML V1.1. It is therefore a different protocol altogether,
and it does not interoperate with pure SAML V1.1 implementations (such
as Shibboleth).
> so schemes that are
> built above existing ones (I guess SAML is the common base of all of them).
> This level defines the vocabulary and the semantic meaning.
Yes, implementations of the XML schemas of SAML are called toolkits.
OpenSAML, for instance, is a SAML toolkit.
> In the second level we have the profiles (?),
Correct. Shibboleth is in this category.
> so, what can be done using
> those schemes and how is done; for example, which are the steps must be
> performed to do a SSO or actions that are possible (defined) in one "tool"
> and not in another.
Correct.
> So, Shibboleth defines one way for doing the things and
> Liberty another and SAML2.0 another.
No, not quite. Shibboleth doesn't specify any new profiles (except
for AuthnRequest and an attribute exchange profile, neither of which
SAML V1.1 specifies). Rather it *implements* the SAML V1.1 profiles.
Liberty ID-FF, on the other hand, *does* specify new protocols and
profiles (based on the SAML V1.1 protocols and profiles).
> So, in that level it would be possible
> to classify the actions that are possible (SSO, federation,...).
>
> Is that more or less right or I am complete lost?
I think you have a pretty good understanding of the problem space. :-)
Cheers,
Tom
