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: RE: [saml-dev] Concern about SAML assertion signing in the SOAP profile

Michael -
If I understand the issue correctly, I believe SAML has addressed this issue
from the very beginning via SubjectConfirmation. For the browser POST
profile, this is set to "bearer", which basically means the entity that
presents the assertion. Other profiles could (and probably should) use
SubjectConfirmation methods that enable the relying party to ascertain that
the assertion in fact belongs to the party that is presenting it. See
section, SAML 1.1 Assertions and Protocols


Jahan Moreh
Chief Security Architect

-----Original Message-----
From: Michael.Mccormick@wellsfargo.com
Sent: Monday, January 19, 2004 12:11 PM
To: saml-dev@lists.oasis-open.org
Cc: goldenbj@wellsfargo.com; Jim.Wolf@wellsfargo.com;
Subject: [saml-dev] Concern about SAML assertion signing in the SOAP

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

To unsubscribe from this list, send a post to
saml-dev-unsubscribe@lists.oasis-open.org, or visit

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