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


Help: OASIS Mailing Lists Help | MarkMail Help

bdxr message

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

Subject: RE: [bdxr] Using SAML with ebMS 3.0

Thanks,  I was aware of START for some time and have now done some work on comparing the two this week.  In this email I'll focus on the "Holder-of-Key" subject confirmation method. Ian Otto of the Australian government kindly answered some of my questions during the ebMS TC call this Wednesday (but the content of this email and any errors in it, which I'm sure there are, are mine). His draft does not sub-profile the SAML profile in any way. It uses the SAML token profile as it is implemented and widely used today. I'll call this the "conventional" way to distinguish it from START. As ebMS 3.0 is SOAP-based and uses WS-Security, the WS Security SAML token profiling is applicable. The draft mainly defines aspects specific to the use of the SAML token profile with ebMS, such as PMode configuration, error handling etc. Ian has uploaded a new version of his document earlier this week which we discussed. 
Apart from the specifications,  I found it useful to look at some examples in XML format so they can be inspected in an XML editor.  Attached are a sample ebMS 3.0 message with embedded SAML assertion from Ian, the SAML example from START (extracted from the PDF) and an example from the official OASIS WS-Security SAML token profile, the current version of which is the 1.1.1. OASIS Standard version and which both specifications follow.
The main benefit of using the SAML token profile is that the receiver of a message, say a large hub that receives messages from many partners, does not need to configure its security settings to trust certificates from all its individual partners.  Instead,  it establishes a trust relationship with a select set of identity providers. The trust relationship means that the receiver accepts messages signed using tokens issued by these identity service providers.   The sender typically obtain such tokens using the WS-Trust protocol, where the identity service provider is referred to as a security token service (STS).  But how tokens are obtained is an agreement between sender and STS and irrelevant to receiver. WS-Trust is another OASIS Standard. 
The SAML assertion is signed by the STS. The signing certificate of the STS must be configured in the receiver to be trusted. As long as the sender is in the possession of a valid security token issued by a trusted STS, the receiver accepts the token sent by the sender. This is the same as for certificates and certificate authorities. The keys included in subject confirmations in the included SAML assertion need not be previously known by the receiver. Common practice (and the default in some toolkits, apparently) is for those keys to short-lived symmetric keys. Revocation is not an issue as the token has a limited lifetime, expressed as NotBefore and NotOnOfAfter timestamps. If used, symmetric keys are encrypted and can only be decrypted by the receiver. The STS also supplies any symmetric keys in unencrypted form to the sender who can prove of possession of the key.   Public keys, which START uses, are also supported.
Some comments and thoughts:
One of the main reasons for using a four-corner model is to simplify the management of certificates.  If millions of entities are interconnected less than a thousand service providers, the management certificates is reduced immensely.  If those providers can agree to use a dedicated CA and trust any certificate issued by that CA, then the management issue is reduced even more.    But this same benefit can be achieved by establishing a trusted infrastructure of security token service providers.   
Furthermore,  such an infrastructure may already exist or be emerging for other purposes (such as federated identity management).  This is the background to the Australian interest in using SAML tokens with ebMS 3.0, as they have an existing SAML based identity management infrastructure that Australian businesses use and this profile would allow them to reuse that infrastructure for business messaging. Similar initiatives exist in other geographies, e.g. in Europe for cross-border e-government services.  The concept of SAML tokens, which inherently have a short lifetime, is much more fine-grained and flexible than relying on certificate revocation. 
In the conventional use, it is the original sender who authenticates to the STS and then uses the obtained token in messages it sends to the receiver.  In START, the message is not sent by the original sender (Corner 1) who obtained the token but by a service provider (Corner 2).   Therefore Corner 1, which obtains the token, needs to supply the public key of Corner 2 to the STS as Corner 2 needs to prove possession of the key and would otherwise not be able to send messages on the original sender's behalf.  Corner 1 must then transfer the token to Corner 2. Corner 1 does not seem to have any  control over the actual message and content as sent by Corner 2 to Corner 3.
In the conventional model, there are typically few restrictions on the keyinfo confirmation data, which can even be a symmetic key.  In START/PEPPOL, it seems it has to be a public certificate issued by a designated community CA, but it is not clear where this constraint is enforced.
The ebMS 3.0 profile defines a processing mode parameter that allows a receiver to specify accepted token services.  The sender can use this information to find out which STS to use.  START/SML/SMP do not seem to allow recipients to specify from which services they accept tokens.    In some jurisdictions,  there may be regulation on service providers and lists of preapproved service providers may exist.   The ETSI TSL (Trust Service List) format could be used as a format to publish such lists. 
Good weekend,

From: bdxr@lists.oasis-open.org [mailto:bdxr@lists.oasis-open.org] On Behalf Of Kenneth Bengtsson
Sent: 16 May 2013 18:25
To: Pim van der Eijk; bdxr@lists.oasis-open.org
Subject: Re: [bdxr] Using SAML with ebMS 3.0

Hi Pim

As we talked about yesterday: START uses SAML for the "holder-of-key" type of assertion. In this scenario an identity provider or similar authenticates the sending party and issues the SAML assertion. From your description yesterday it sounds to me like this is very close to what the Australian government wants to do. An overview can be found in the attached document on page 15, "Including a SAML assertion in the Security header" and subsection "Types of SAML assertions" on the same page, and more details on page 16, "Additional Processing Rules for holder-of-key Assertions", chapter 5 "SAML 2.0 assertion profile" pages 20 to 22, and the example on page 25 and 26.

I will be very interested in hearing how the Australian government progresses and what you come up with for ebMS 3.0. It certainly is most interesting for PEPPOL.

Best regards,


From: Pim van der Eijk <pvde@sonnenglanz.net>
Date: Thursday, May 9, 2013 3:34 AM
To: "bdxr@lists.oasis-open.org" <bdxr@lists.oasis-open.org>
Subject: [bdxr] Using SAML with ebMS 3.0

FYI, the Australian government (which mandates ebMS 3.0 for some very large scale data exchanges) will define a profile of the WS-Security SAML profile for use with ebMS 3.0. Like other countries, they have an established SAML based system for B2G communication that this profile would allow them to reuse.   In BDX/BDXR there were earlier proposals to use SAML.  I need to spend more time to understand this proposal, but it seems to have some strong advantages.  It would be useful to to see if BDXR could leverage this work.

Attachment: australia.xml
Description: Binary data

Attachment: start_saml.xml
Description: Binary data

Attachment: wss-m_saml_token.xml
Description: Binary data

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