RE: [security-services] ECP SSO Profile and Metadata

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

> Ok, then from an implementation standpoint, it's perfectly 
> fine to have a different endpoint that handles SSO 
> (AuthnRequest) using SOAP and one that uses HTTP-Redirect, 
> for example.

Oh, definitely. Otherwise metadata wouldn't need to identify the binding and
location together in the endpoint. If anything, the metadata schema is
optimized for that case, and you get duplication when you overload bindings
on the same endpoint.

> This is actually an interesting question. So you are 
> proposing, and I believe I agree now, that since this is the 
> SP SSO Descriptor, it should be PAOS because that is the 
> binding it is using on this endpoint.

Right. It's half and half, SOAP and PAOS.

> And therefore it is up 
> to the IDP to determine this endpoint and stick it inside the 
> Response destination attribute and the SubjectConfirmation 
> recipient attribute.

Yes, but with the same rules as with any of the other profile/bindings, you
process what's in the AuthnRequest with the metadata and come up with the
right binding to use. It's just a little more complex here because the PAOS
binding isn't really dictating your response, but the client's.

> Secondly, it must realize that the 
> Response is going to an ecp so the actual binding the IDP has 
> to use to respond to the AuthnRequest is a SOAP/ecp response 
> (unrelated to PAOS at all). So yes, I agree that the SP SSO 
> Descriptor should say declare its binding as urn:...:PAOS.

Right. A little odd I guess, but the whole exchange is a bit odd.

> > Looks like errata in the example to me. 
> 
> So SAMLProfiles, line 964 should be changed to: 
> "responseConsumerURL="https://ServiceProvider.examaple.com/ecp_
> assertion_consumer" 
> 
> For consistency in the example. 

Whichever, either one could change. But the identity-service hostname in the
example, while well-intended, is probably just confusing since it sounds too
much like identity-provider.

-- Scott