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

[Greg Whitehead <grw@trustgenix.com>]

On Jun 23, 2005, at 7:04 AM, Thomas Wisniewski wrote:

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

Not sure which part of my message you are referring to here, but I 
think the IDP SingleSignOnService Binding should be SOAP and the ECP 
AuthnRequest ProtocolBinding should be PAOS (since this is how the SP 
expects the response to be delivered).

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

Agreed.

> Tom.
>
> > -----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
> > > OASIS
> > > at:
> > >
> > 
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >