RE: [security-services] Text for response in SAML FAQ

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

Some corrections...

> Specifically regarding message signing, SAML 1.1 allows for assertions
> to have an WSU ID (wsu:ID) attribute.

No, it doesn't. SAML uses its own local ID attributes until such time as
there's a reasonable alternative in accepted use (e.g. xml:id). SAML 1.0 had
no ID attributes, which is why signing was a problem and usually avoided.
SAML 1.1 has AssertionID (and RequestID, ResponseID). SAML 2.0 has ID. All
are unqualified (in the empty namespace).

> This attributes is what is used
> by most Java APIs to sign SOAP messages.  The .NET WSE 1.0 
> doesn't allowthe wsu:ID attribute.  Instead, it uses the assertion:Id to
> sign saml:Assertion elements.  This creates a conflict as Java uses one
> identification means and .NET another.

Signing SOAP is orthogonal to signing SAML, but there's no way to slip
another ID attribute (wsu:Id or otherwise) into a SAML object. It would be
invalid XML. I don't know if .NET follows the SAML 1.1 spec's signature
profile or not, but the profile requires a Reference with a URI pointing at
the containing object's ID.

> One potential solution requires that all apis involved add both an
> assertion:Id and wsu:ID attribute to the saml:Assertion elements, and give
> both ids the same value.

That would be illegal in XML.

There's only one general way to sign SAML itself (at least in 1.1 and 2.0).
The SOAP/WSS situation may be muddier, I don't know. But that's quite
separate.

As a FAQ item, we may want to clarify the difference between signing SAML
objects and signing them into SOAP. The former is dictated by SAML. The
latter is dictated by WSS.

A related FAQ is of course the difference between the SAML SOAP binding,
which has nothing directly do with WSS, and often doesn't require signing at
all, and the SAML token profile.

-- Scott