Title: SAML, trust and WS.
Where the user gets the Assertion from ? IDP
? In the federated example/SSO it was clear what the relationship
between user/SP/IDP was. with the Wsse I kind of don't get the full
picture.
This has to be profiled within some other
specifications. The SAML specifications profile a few cases such as
browser based SSO, but do not profile a web services use
case.
The Liberty Alliance ID-WSF specifications do profile
this use case including defining an Authentication Service (which would
typically be exposed by the SAML IdP), Discovery Service, and Application
Service invocation framework.
The Service somehow will have to trust the
Asserting party even though in different trust domains ? Or this means that
the user can only be authenticated in his trust domain ?
The Service will need to accept ("trust") the statements made by
the issuer of the assertion (assuming the client met the terms of the
subject confirmation and conditions). I would say this means that the
Service is in the same trust domain as the issuer (not necessarily the same as
the client as it's the issuer that is important for the
recipient).
The SAML message will need to contain all the
information necessary to the Service A to make the decision. I mean Service A
don't need to go somewhere else to check that the assertion is valid as he has
got all the info he requires. I guess it's here where subject confirmation
might come in place ?
I would not say this is a SAML message. I would say this is
an application message that carries a SAML assertion within the security context
for the message. The profile that I spoke about above would need to
profile things like what are the requirements for binding the assertion to the
message.
Note that Service A could validate the token itself, or could send
it to some other party to do the validation (such as the issuer). I
know of some implemetnations that have done this in order to ease the
implementation at the recipients.
Another alternative, btw, if you are going to use non-signed
messages, is to use the WSS SecurityTokenReference to carry a reference to
the token so the SP can retrieve the token directly from the issuer (this
can have substantial savings in processing as in many cases the token won't need
to be signed since it is going directly from the issuer to the relying
party rather than going through a third party.
Conor
