[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] ECP SSO Profile and Metadata
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]