I finally got around to looking at this...
I agree that it would be nice for profile to be called out in endpoint
metadata, to allow selection of an endpoint specific to a particular
profile. It would also be nice for profile to be called out in the
request, so that compatible profiles could be handled on a single
endpoint.
Anyway, even without that, I think we're OK in this case if we suggest
that ECP AuthnRequests specify ProtocolBinding="urn:...:PAOS" (or refer
to a PAOS AssertionConsumerService endpoint). This gives the IdP enough
information to respond with the ECP header from the SOAP endpoint. An
AuthnRequest received at the SOAP endpoint with
ProtocolBinding="urn:...:SOAP" could be handled differently.
The bigger issue, I think, is that the SOAP endpoint at the IdP is
allowed to return login forms etc before returning the SOAP response,
so it's not really strictly speaking a SOAP endpoint (ie I think this
is the reason we probably should have assigned a SOAP-ECP binding URI).
-Greg
On Jun 20, 2005, at 12:07 AM, Scott Cantor wrote:
>> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
