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

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

> Technically, speaking the SSO endpoint should NOT be 
> urn:...:SOAP, but rather something different like SOAP-ECP 
> (must like HTTP-xxx is formulated). Consider the technical 
> possibility of issuing an AuthnRequest over SOAP (like one 
> might issue an AttributeQuery). The mechanisms of how these 
> are sent and processed would be completely different (much 
> like HTTP-Post and HTTP-Artifact are different albeit they 
> use HTTP).

Well, this is technically true, and I suppose the reason it wasn't addressed
is that nobody proposed a profile involving any other use of SOAP on this
endpoint.

> endpoint is SSO with binding "urn:...:SOAP". However from an 
> implementation standpoint, one does in fact need to overload 
> these 2 SOAP-based bindings inside of one endpoint. So if you 
> were attempting to handle "urn:...:SOAP" in a generic way, 
> you are out of luck.

Not only that, but technically you wouldn't have any way to know
definitively whether to send the ECP response header block. There's nothing
sent to the IdP from the EC in this profile other than a plain vanilla SOAP
request. It would look identical to any other use of SOAP to submit an
AuthnRequest. You could do something like assume ECP if the ACS endpoint
used is PAOS, I guess. Kind of ugly, I agree.

Since I doubt this profile has been widely implemented yet, it's probably
worth defining an extension mdext:Profile attribute to the
SingleSignOnService endpoint and using that as a potential profile
indicator. Absent it, any SOAP endpoint would be assumed valid for this
profile, but with it specific profiles could be targeted at specific
locations.

This kind of approach would handle any case where a single element + binding
doesn't uniquely identify a profile.

This is why I made sure to include <anyAttribute ##other> in EndpointType. I
think one of the mistakes we made (again) in 2.0 was not uniformly adding
wildcards. They are *always* needed eventually.

-- Scott