OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx message

[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]