RE: [saml-dev] Concern about SAML assertion signing in the SOAP profile

[Scott Cantor <cantor.2@osu.edu>]

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

No, that's not what it's for. In a small sense, the unique ID is used as a
replay detection tool, but that doesn't prevent theft of the token before
it's ever used. What you're talking about is addressed by subject
confirmation. You seem to be assuming that bearer is the only option.

> 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.


Not if the subject confirmation is holder of key. Then you have to sign the
header and prove possession of the key. If you insist on bearer semantics to
avoid the second signature, then, well, yeah. Theft is pretty much all you
need to spoof the subject.

> 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
> envelope).

There is, though not if the subject doesn't have a key.

> 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.

That's not what authz assertions are for. They are for a PDP to issue a
response to a request from a PEP. What you're describing is a capability
assertion, I think. And what you're talking about inserting is really just
the Resource, which is already in the schema.

> Has this issue been addressed?

I think so, though not in a scenario with intermediaries.

-- Scott