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

[Greg Whitehead <grw@trustgenix.com>]

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