Moving closer to a profile of SAML a comment on -- Securing EBMS3 with SAML Tokens V1.1

[Dale Moberg <dmoberg@axway.com>]

1. MEPs and Token flows, preliminary…

 

WS-Trust is mentioned in section 1, first paragraph, and generically described in the new section 1.16.1 (the section numbering scheme is a bit broken)

Here the distinctive WS-Trust terminology (STS,claim) is rolled out. But it is difficult to tell just what parts are meant to be informative background and which as normative profile.

For example, it is stated that “The SOAP Receiver will have expressed which Identity Providers it will honour and which claims are required in a policy document (usually WSDL).”

Normally ebMS 3 (or its profiles, like AS4) has not required either WS-Policy, Policy attachments, or WSDL.

Earlier (section 5) you had:  PMode[1].Security.SAML.IdP: The value of this parameter is a list of the URLs of IdPs acceptable to the SOAP receiver. Each IdP URL may additionally have an associated URI by which the IdP knows the SOAP receiver. If absent, the default should be used. (This is normally the URL of the receiver endpoint.)

I am thinking that the references to Policy, WSDL etc are not really part of the specification/profile but just informational. Informational background is OK if it is needed to understand the specific profiling or specification being made. Otherwise it can be distracting and/or confusing by suggesting that the PMode[1].Security.SAML.IdP   is to be extracted from Policy attached to a WSDL. So I think the background information needs to be pruned down to just what is needed for understanding tokens – their formats, their contents, their options, and then also the MEP flows that are enhanced by STS flows and token content. ebMS3 does not really explain where the PMode values come from, so it is OK to leave this open in a profile.

 

2. Working core example of a “pull mode” request using SAML

Because authentication is particularly important for authorization in the “pull mode,” I was looking for the pieces that would be needed for a pull client to use SAML Authentication Assertions when contacting a server with a mpc (or queue).

I think what is involved at run time is:

1. MSH pull client (SOAP sender)  formulates a SAML Request and sends it to an IdP/STS trusted by the MSH server (queue operator). The URL of this STS is stored in a PMode of the SOAP Sender.

[would be very nice to have an example AuthenticationRequest for this]

2. The STS (assuming the Authentication Request meets all its verifications) then issues an Authentication response (in the backchannel, I am assuming) containing an AuthenticationAssertion  

[would also be nice to have an example wire format for the response to the AuthenticationRequest]

3. The MSH sender processes the SAML Authentication response and assembles a message something like that in section 4 (but for a Pull signal, rather than a push user message).

4. Pull mode continues as usual.

5. If a NRR or receipt awareness is needed for the pull-mode user message that is received, will another STS trip be needed? Etc.

 

I am wondering whether the TC should view the SAML specification as generic for ebMS3, or customized profile for use with the pieces of ebMS3 found in AS4? It might be viewed as an additional conformance profile for using SAML with AS4, and that might make it easier to write.