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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[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
Security Architect
VANguard and Infrastructure Branch
eBusiness Division

Department of Industry, Innovation,
Science, Research and Tertiary Education

SAP House, Level 8.49, Bunda Street, Canberra City ACT 2600
GPO Box 9839, Canberra ACT 2601
Ph: +61-2-6276 1660 Fax: +61-2-6213 6684
Mobile: +61 403 458 215
Internet: http://www.innovation.gov.au
ABN 74 599 608 295


From: ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org] On Behalf Of Dale Moberg
Sent: Wednesday, 22 May 2013 3:46 AM
To: Otto, Ian; ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] Moving closer to a profile of SAML a comment on -- Securing EBMS3 with SAML Tokens V1.1


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 information contained in this e-mail, and any attachments to it,
is intended for the use of the addressee and is confidential.  If you
are not the intended recipient you must not use, disclose, read,
forward, copy or retain any of the information.  If you received this
e-mail in error, please delete it and notify the sender by return
e-mail or telephone.

The Commonwealth does not warrant that any attachments are free
from viruses or any other defects.  You assume all liability for any
loss, damage or other consequences which may arise from opening
or using the attachments.

The security of emails transmitted in an unencrypted environment
cannot be guaranteed. By forwarding or replying to this email, you
acknowledge and accept these risks.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]