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

Greg, agree with your sentiments completely.

Next week I'll propose some text for errata (slightly different than your comments below). Basically, I will propose that the endpoint for AuthnRequests (i.e., the Single SignOn Service endpoint) be "urn:...:SOAP" and not "urn:...:PAOS". One reason is that for this version of SAML thihs is unambiguous. Another reason is that PAOS is not appropriate (since there is NO PAOS processing at all at the IDP). I assume you probably mean to say "urn:...:ECP" but of course that's not defined as a binding in [SAMLBind]. The last reason is that I think the binding definition in MD implies the binding the input msg is coming in on (generally speaking) -- which in this case does not mean it's the one going out (where we have SOAP -> HTTP or SOAP -> ECP, in this example). So I think using SOAP is sufficient.

You didn't mention the SP side where PAOS/ECP is used. I assume that there is no contention here and that using "urn:...:PAOS" for the AssertionConsumer Service endpoing is the correct solution.


> -----Original Message-----
> From: Greg Whitehead [mailto:grw@trustgenix.com]
> Sent: Thursday, June 23, 2005 1:26 AM
> To: Scott Cantor
> Cc: 'SAML'; 'Thomas Wisniewski'
> 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
> > 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]