[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-sx] WS SX Additional Interop Scenarios
Anthony Nadalin wrote: > 1. "Requestor obtains SAML 1.1 Bearer Token from STS" > a. The SAML token is signed by the STS - is this the actual SAML token > being signed or the header with the token ? > [PM] The SAML token is signed. The idea here is that a bearer token is obtained from the STS against the requestors credentials. There are no further steps in this flow, tho' it is easy to imagine the requestor placing the SAML assertion in a SOAP header and transmitting to the recipient. [\PM] > 2. " Requestor obtains SAML 1.1 HoK Over Bilateral HTTPS" > a. This seems to involve some WS stack changes, and I'm not sure how > we indicate that this is what is being requested by the WS stack > [PM] I am not sure what you mean by "WS stack changes". The idea here is to show how SSL, SAML HoK and WS-Trust work together. The STS returns a SAML HoK token with information about the SSL client-certificate carried in the SAML <SignatureConfirmation> element. There are no further steps in this flow, tho' it is easy to imagine the requestor placing the SAML assertion in a SOAP header and transmitting it over bilateral SSL to the recipient. The recipient would be able to compare the client certificates used for SSL vs. the certificate info found in the SAML assertion. Chris Kaler has remarked that the RST/RSTR message pairs in here look identical to 1 above. In other words, this is more a SAML use-case than a WS-Trust use-case; this may be true and I am working on the writing out the relevant RST/RSTS messages. [\PM] > 3. "Requestor obtains SAML 2.0 Bearer Token from STS OnBehalfOf User" > a. I think that this would just fall into a OnBehalfOfUser" case and > not specific to SAML 2.0 Bearer Token > [PM] I have used SAML 2.0 here as SAML 2.0 can represent information about both the subject and the bearer (or attesting entity). In this case, the requestor acts as SAML bearer and is distinct from the subject (identified by OnBehalfOf). This could be respun as generating a SAML 1.1 assertion. If we were to do so, there wouldnt be an easy way to represent information about the bearer within the assertion. In other words, in SAML 1.1 the bearer and the subject are identified. When the requestor uses the SAML assertion (in a SOAP header) it acts as the onBehalfOf identity as opposed to speaking for it. [\PM] > 4. "Requestor obtains SAML 2.0 HoK Assertion OnBehalfOf User Over > Bilateral HTTPS" > a. same issues as #2 and #3 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]