Giuseppe,
this is something we're (attempting) to look at - Browser/SSO combined with WS-Security stuff for accessing further web services. I've tried to summarise what we want:
http://www.weblogs.uhi.ac.uk/sm00ay/?p=164
Is the document (at the foot of the page) any use to you? It's at a very early stage so not sure which way it will go. We initially looked at the contrained delegation profile but there are a few questions, outlined in the document.
If you can point out any glaring errors in our approach, it would be most helpful!
Alistair
On 5 Dec 2005, at 15:18, Giuseppe Sarno wrote:
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
