Title: Message
Hi,
just
one more thing:
Could
the Saml Token be used together with the SSO profile ? I'll be more
clear.
Browser/client tries to access Resource A on
SPA.
The
SPa uses the SSo profile to authenticate the User and is going to get back an
assertion.
It (if
policy applies) will grant access to Resource A which actually is aclient
for a Web Service B.
resource A on SPA could use WS- or Liberty profile now to access that Web
Service using the SAML assertion?
does
this picture make sense to you or what is missing ?
Thanks.
Giuseppe.
-----Original Message-----
From: Cahill, Conor P
[mailto:]
Sent: 05 December 2005
14:50
To: Sarno, Giuseppe [MOP:GM15:EXCH];
Subject: RE: [saml-dev] 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
