RE: [security-services] Trust in artifact resolution

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

Josh Howlett wrote on 2010-02-12:
> Ok, I should explain that I'm asking these questions in the context of
> a new binding that I'm working on. In this case, I'm working on the
> assumption that the thing-in-the-middle can be trusted by the SAML
> requester to do the authentication.

It's probably a better idea to start fresh then rather than try and adapt
anything based on a browser binding. And I'm not sure I would ever advocate
artifacts if you don't have to have them. Unless the issue is message size,
they really serve no purpose other than to make things complicated.

> (I don't believe that SAML has a generic term for the thing-in-the-
> middle that is the user agent in the HTTP Artifact Binding in the
> context of artifact resolution, but please correct me if I am wrong)

It's not a generic binding, so the term is "HTTP user agent". If there isn't
one, the binding doesn't really apply.

> So it does. It does provide some flexibility in how this is achieved:
> "...or using a binding-specific mechanism". However, I assume that
> this is meant to refer to the binding used by the Artifact Resolution
> Protocol (e.g., SOAP binding), rather than the binding-in-development
> used to transport the artifact to the SAML requester.

Yes. An artifact is just a bearer reference to be turned into a message by
directly contacting the artifact issuer. If that isn't the scenario, I would
probably avoid any use of the term or the machinery because it will just be
confusing.

> I think I'm stuck. Do you see any possible strategies for resolving this?

Avoid artifacts at all costs and communicate signed messages directly
through the intermediary. Or architect the profile such that there is no
SAML requester/responder relationship between the endpoints and instead
develop it as two separate exchanges where the party in the middle is an
active participant.

> (I want to avoid authenticating the SAML requester to the SAML
> responder, and vice versa; but it's fine for the thing-in-the-middle
> to authenticate itself to both parties).

Then I think it's safe to say that the protocol exchange is not between the
endpoints, but is a pair of distinct exchanges. With SAML protocol, you
*have* to be authenticating the parties to get any work done (or you're
punting trust of course).

-- Scott