[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [bdxr] Using SAML with ebMS 3.0
|
Hello,
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,
Pim
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,
Kenneth
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 Hello,
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.
Pim
|
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]