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

[Thomas Wisniewski <Thomas.Wisniewski@entrust.com>]

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

Scott, just one item below.

> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu]
> Sent: Sunday, June 19, 2005 10:14 PM
> To: 'Thomas Wisniewski'; 'SAML'
> Subject: RE: [security-services] ECP SSO Profile and Metadata
>
>
> > Ok, then from an implementation standpoint, it's perfectly
> > fine to have a different endpoint that handles SSO
> > (AuthnRequest) using SOAP and one that uses HTTP-Redirect,
> > for example.
>
> Oh, definitely. Otherwise metadata wouldn't need to identify
> the binding and location together in the endpoint. If
> anything, the metadata schema is optimized for that case, and
> you get duplication when you overload bindings on the same endpoint.
>
> > This is actually an interesting question. So you are
> > proposing, and I believe I agree now, that since this is the
> > SP SSO Descriptor, it should be PAOS because that is the
> > binding it is using on this endpoint.
>
> Right. It's half and half, SOAP and PAOS.
>
> > And therefore it is up
> > to the IDP to determine this endpoint and stick it inside the
> > Response destination attribute and the SubjectConfirmation
> > recipient attribute.
>
> Yes, but with the same rules as with any of the other
> profile/bindings, you process what's in the AuthnRequest with
> the metadata and come up with the right binding to use. It's
> just a little more complex here because the PAOS binding
> isn't really dictating your response, but the client's.

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). So we really talking about something like SOAP-Basic (for lack of a better term) and SOAP-ECP. This way if could, as you confirmed in the first item above, have 2 diff implementations/endpoints for the 2 different types of SOAP-based requests. As it stands now, because of the convenience of not having a profile defined that may use SOAP-Basic and SOAP-ECP, we can get away with say the 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.

>
> > Secondly, it must realize that the
> > Response is going to an ecp so the actual binding the IDP has
> > to use to respond to the AuthnRequest is a SOAP/ecp response
> > (unrelated to PAOS at all). So yes, I agree that the SP SSO
> > Descriptor should say declare its binding as urn:...:PAOS.
>
> Right. A little odd I guess, but the whole exchange is a bit odd.
>
> > > Looks like errata in the example to me.
> >
> > So SAMLProfiles, line 964 should be changed to:
> > "responseConsumerURL="https://ServiceProvider.examaple.com/ecp_
> > assertion_consumer"
> >
> > For consistency in the example.
>
> Whichever, either one could change. But the identity-service
> hostname in the example, while well-intended, is probably
> just confusing since it sounds too much like identity-provider.
>
> -- Scott
>