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