Re: [security-services] Trust in artifact resolution

[Josh Howlett <josh.howlett@gmail.com>]

>
>>> Yes, but it wouldn't prove that you got either one from somebody you
>>> trusted and not some arbitrary interloper.
>>
>> Sure, but we can authenticate the binding used to obtain the artifact
>> to obtain that assurance.

> How? The artifact is passed through the client, so there's no way  
> for the
> message's intended recipient to authenticate it from the message/ 
> artifact
> issuer.

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.

(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)

>> I originally thought there was a violation because I got badly
>> confused. Where is the violation now? The callback does not require
>> authentication...?
>
> The profile says the SAML responder MUST authenticate itself to the  
> SAML
> requester, doesn't it?

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.

I believe that I can achieve equivalent assurances by providing the  
message-hash evidence to the SAML requester using the binding-in- 
development, and comparing this to whatever it happens to resolve  
using the ARP binding (assuming we trust the thing-in-the-middle to  
authenticate the SAML responder). However, I don't think it is  
reasonable to describe this as authentication "...using [a] binding- 
supported mechanism".

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

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

josh.