> I think that in most cases the invocation model (parties and
> security context) will be different and that a token generated
> for browser based SSO will typically be different than a token
> generated for web service invocation
i think this should be stressed over and over. speaking from my
own experience, i bet that there are a lot of developers that are
new to saml, attempting to implement some saml-based security
system but have not grasped that the saml assertion referred to in
the simple saml 1.x sso profile is used for a different purpose
(and in a different context; and using a different delivery
mechanism/protocol) than a saml assertion used in a wsse:Security
header. another thing that us non-experts get easily tripped up
on i think, is that there are significant differences in what you
can do with saml 2 compared to what you can do with saml 1.x. in
the project i am working on, we are constrained to saml 1.1.
the eureka moment didn't come for me until i eventually realized
that 1) saml on its own only goes so far; and 2) the Liberty
Alliance and the ws-* stack are two distinct approaches to the
same problem. the confusing thing is (at least it was for me) the
fact that they both use ws-security and saml assertions. if i
were to advise any newbies out there like myself i would say
first establish from which context (Liberty or ws-*/saml 1.x or
saml 2) a given explanation of saml is coming in order to make
sense of all of the different (often confusing) interpretations
out there.
