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

[Thomas Wisniewski <Thomas.Wisniewski@entrust.com>]

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

Ok, so my attempt at a summary:

1. The SP (either via Authn Request information such as the protocolBinding, ACS index, or ACS Url, or through the metadata ACS default) will dictate to the IDP Single SignOn Service which endpoint is to be used for the reponse (which implies the binding to use as well). This is true even if the binding does not match the expected one (e.g., HTTP-based for an ECP SOAP Authn Request).

Example:
- ECP -> SOAP Authn Request with ACS index 1 ->
- IDP does not have ACS index 1 for the SP, and the default is an ACS with binding  Artifact.
- IDP completes local signon, if required, etc...
- IDP -> HTTP-Artifact Response -> ECP
- ECP can process this as an incorrect response and send an error to the SP (or do nothing I suppose).

2. The protocolBinding value urn:...:PAOS can be used to tell the IDP Single SignOn Service to respond with an ACS whose binding is PAOS. If for some reason there is more than one endpoint for PAOS (non of which are the default) and the ACS Url does not accompany the AuthnRequest, then *one random* endpoint may be used by the IDP.  I assume this is true in general (seems to beg for an isDefault per binding per service indicator in the future).

The main point here is that PAOS should be used as the ACS url binding in metadata. Specificially, if someone was to use "urn:...:SOAP", then the IDPs should be allowed to (a) say SOAP is not supported (i.e., you should have used PAOS as the protocolBinding), or (b) reespond with the standard SOAP-based response (i.e., an SAML Response message wrapped in SOAP -- and NO ecp:Response).

Nick, I don't see that we are changing or need to change the ecp Request/Response messages in any way here.

Tom.

> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu]
> Sent: Thursday, June 23, 2005 11:10 AM
> To: 'Greg Whitehead'
> Cc: 'SAML'; 'Thomas Wisniewski'
> Subject: RE: [security-services] ECP SSO Profile and Metadata
>
>
> > Sure, and in my original message I think I mentioned that
> the SP would
> > either specify a PAOS AssertionConsumerService endpoint or
> specify PAOS
> > in ProtocolBinding. What I think we should advise against,
> in the ECP
> > case, is leaving the response binding completely unspecified, since
> > then there is the potential for ambiguity at the IdP SOAP
> > SingleSignOnService (if we define some other profile that
> > uses SOAP at the IdP in the future).
>
> Definitely, but I don't think it's possible to leave it
> completely unspecified, short of there being no default
> endpoint in the metadata, which is more or less impossible.
>
> The worst case scenario is you do SOAP in, and the default
> endpoint is something incompatible with that (HTTP based),
> although even that's sort of a matter of opinion. A client
> could theoretically bang SOAP in, and get back a redirect or
> form with the response. ;-)
>
> But sure, as a guideline, clearly any request ought to really
> carry *something*. Leaving it out entirely usally seems like
> a bad idea.
>
> -- Scott
>