OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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

Scott, thanks, see below.

> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu]
> Sent: Sunday, June 19, 2005 4:52 PM
> To: 'Thomas Wisniewski'; 'SAML'
> Subject: RE: [security-services] ECP SSO Profile and Metadata
> > 1. When the ECP talks to the IDP, the IDP SSP Descriptor
> > metadata setting it would use would be the Single Sign-On
> > Service endpoint with a binding of urn:...:SOAP.
> Well, I don't think it was ever a given that clients would
> use the metadata. They could, but I think they usually end up
> having the URLs provisioned directly. But yes, the binding
> used to the IdP is SOAP.

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.

> > 2. When an SP publishes its metadata, what is the binding of
> > the Assertion Consumer Service endpoint that is used by ECP
> > callers. I.e., is it urn:...:SOAP or is it urn:...PAOS? Since
> > the IDP doesn't really care/know about ECP, I assume the
> > value should be urn:...:SOAP?
> I would say it's PAOS, since that's what the binding in use
> is on that leg. But whatever, should be clarified.

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. 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. 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.

> > 3. When the IDP is sending back a response to the ECP,  it
> > should only ever be sending this back to an Assertion
> > Consumer Service whose endpoint is SOAP/PAOS (as answered in
> > 2 above)? I.e., for a SOAP binding based AuthnRequest, the
> > assertion consumer url that gets identified (whether by the
> > AuthnRequest data such as AssertionConsumerServiceURL,
> > AssertionConsumerServiceIndex, ProtocolBinding,   or whether
> > by the  IDP using the default endpoint for this service) must
> > have a binding of SOAP/PAOS for things to work.
> I'd think so.
> > 4. I assume the ECP examples related to xxxConsumerURL in
> > [SAMLProf] should probably be fixed so that they correlate.
> > I.e., the SP is sending a value of
> > http://identity-service.example.com/abc whereas this should
> > be the assertion consumer url that the IDP defines in the
> > ecp:Response AssertionConsumerServiceURL?
> 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.

> -- Scott

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]