[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [saml-dev] SAML, trust and WS.
Hi, >could be consumable at multiple destinations using different subject confirmations (you can have more than one). So what you are saying is we could have the Bearer ConfirmationMethod for the local SP and a HolderofKey for the remote WebService. Are you referring to the Recipient (or address) option (of SubjecConfirmationData) where we can specify the network for example. (Core page 19) Thanks. Giuseppe. -----Original Message----- From: Cahill, Conor P [mailto:conor.p.cahill@intel.com] Sent: 08 December 2005 15:22 To: Sarno, Giuseppe [MOP:GM15:EXCH]; will@javafreelancer.net; saml-dev@lists.oasis-open.org Subject: RE: [saml-dev] SAML, trust and WS. > a) SPA to do SSO with IDPA and so get an Assertion(SSO). > b) ResourceA actually now needs to invoke WebServiceA but he > now needs an WS assertion. So he will then need a new Assertion ? Usually yes, although it is possible that the same assertion could be consumable at multiple destinations using different subject confirmations (you can have more than one). > The problem here is how can I bundle this together ? > If I don't bootstrap from SSO how can I get the WebService > Assertion (SAML Token) ? Well, either you bootstrap from SSO or you require that the user authenticate to you directly -- otherwise how do you know who the user is? In Liberty ID-WSF this is solved by defining an attribute added to the SSO assertion which contains a EPR for the user's discovery service. The SP can then access the DS and retrieve the necessary information to invoke the web service to get at resource data. Conor
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]