RE: [security-services] Trust in artifact resolution

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

Josh Howlett wrote on 2010-02-11:
> Section 5.4.2 ("<ArtifactResponse> Usage") of SAML2Profiles states
> that "The responder MUST authenticate itself to the requester and
> ensure message integrity, either by signing the message or using a
> binding-specific mechanism".
> 
> I'm curious about the requirement to authenticate to the responder.

It's to provide trust in the assertion. If you don't care who the issuer is,
then you can "authenticate" them however you like and I suppose if the
issuer only wants to support such relying parties, it can do so by "not"
authenticating itself.

> For example, imagine an SAML artifact format that carried a hash of
> the SAML message. The requester could verify post hoc that the
> resolved assertion was genuine by calculating the hash and matching
> this value to the value in the artifact.

Yes, but it wouldn't prove that you got either one from somebody you trusted
and not some arbitrary interloper.

The point here is that the artifact binding relaxes the requirement to
explicitly sign the assertion because you're talking directly to the issuer,
whereas with POST you're not, so signing is the only way to authenticate the
XML. So it finesses the requirement by saying that artifact usage means you
can authenticate in either a message-oriented or transport-oriented way.

> If a binding where to use this mechanism, would this violate the
> requirement set out above?

Probably in the strictest sense, but really any of the security requirements
can be turned into no-ops by claiming you "did it by ignoring it".

A problem SAML has always faced is that when it says MUST, the "low end"
crowd claims it's too strict and when it says SHOULD, people attack the
"insecurity" of the standard. Rock, meet hard place.

-- Scott