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


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

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

Subject: Concern about SAML assertion signing in the SOAP profile

SAML 1.1 clarifies how to go about applying a digital signature to an
assertion, which is an important safeguard against man-in-the-middle attacks
involving credential tampering or forgery.

My question is whether this digital signature is sufficient safeguard
against credential replay attacks.

In the web browser profile this is a minor concern.  The assertion is
provided to clients presenting a valid SAML artifact over a secure,
authenticated HTTPS channel.  Exploiting a stolen assertion would probably
be prohibitively difficult in this scenario.

In the SOAP profile it is more worrisome.  Anyone possessing a valid SAML
assertion could apparently attach it to the SOAP header (as prescribed in
the SAML-SOAP binding) of a web service request, thereby associating the
identity in the assertion to the request in the SOAP body.  For example, if
I can steal a SAML assertion created for William Gates, I can use it to
request a withdrawal online from his bank by binding the assertion to a SOAP
request.  Digital signing of the assertion does not stop me from exploiting
it -- in fact, it makes it more likely the SOAP provider will render me
service as William Gates.

SAML provides methods of preventing assertion theft (e.g., recommending use
of SSL) and limiting the time period during which a stolen assertion can be
exploited (expiration/TTL elements).  While these are laudable, they're
arguably insufficient.

What SAML 2.0 ought to do is address the SOAP replay issue head-on.  There
should be a cryptographic mechanism for binding a ws-security credential to
the SOAP message (e.g., a digital signature encompassing both token and

There should also be a way of creating SAML assertions that are specific to
a SOAP request.  For example, an authorization assertion that contains a
unique WSDL signature or UDDI identifier indicating what SOAP services the
bearer is allowed to request.

Has this issue been addressed?

Michael McCormick
System Architect
Wells Fargo Services Company
255 Second Ave. South
MAC N9301-027
Minneapolis MN 55479
> *  612-667-9227 (voice)
> *  612-590-1437 (cell)
* 612-621-1318 (pager)
> *   612-667-7642 (fax)
> *  mailto://michael.mccormick@wellsfargo.com
> *  m.mccormick@acm.org

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