[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Moving closer to a profile of SAML a comment on -- Securing EBMS3 with SAML Tokens V1.1 [SEC=UNCLASSIFIED]
|
Hi Dale, Thanks for the comments. I will see what I can do to make it clear what is informative and what is normative. WSDL and WS-Policy are an implementation
option, one that is commonly chosen, but not the only way to do things, so I will make that clear. For similar reasons, I have not included the WS-Trust call to obtain the SAML token. WS-Trust is not the only mechanism for obtaining the token, but it is the
most common. If you think it a good idea, I can include a sample of the WS-Trust call to show the relationships in a typical transaction. Additional comments interspersed below: Regards, Ian Otto. Ian Otto Department of Industry, Innovation,
SAP House, Level 8.49, Bunda Street, Canberra City ACT 2600 From: ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org]
On Behalf Of Dale Moberg 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] My understanding of PModes is that they are exchanged out of band at some point in order to facilitate connection
between MSHs in different organisations. The URL of the STS is specified in the SOAP Receiver. The SOAP sender will have obtained access to this so that it knows which identity provider/STS to contact. 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] I can do that using WS-Trust as an example which is the most common way of obtaining a token, but it may not be the
only way. 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). I can easily mock up a sample for the pull signal. 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. Further SOAP calls can be made up until the token expires, usually 30 minutes, but that depends on the policy of the
identity provider. 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. From an Australian Government perspective, we want the vendor community to have some certainty around how SAML can
be used in AS4. Having said that, some are also cherry picking other features from the wider standard and saying that is a must as well. At this point, I am happy to take the TCs recommendation as to how to proceed. ************************************************************************* The Commonwealth does not warrant that any attachments are free The security of emails transmitted in an unencrypted environment |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]