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

["Nick Ragouzis" <nickr@enosis.com>]

On a quick read I'm not following.

As far as the actual exchanges with the ECP, the specs have
the specific requirements: SP <-PAOS-> ECP, ECP <-SOAP-> IDP.
Maybe it can be reinforced, but SAMLProf has that much.
Greg's idea also has the benefit of making absolutely clear 
to an IdP that the initial SOAP request is certainly an ECP 
case.

Apart from Greg's idea of a SOAP-ECP binding for IdPs, I'm
only addressing the semantics of the paos:Request and
ecp:Response. 

And, in dealing with that, if the SP leaves the IDP to it's
own devices (nothing in the <AuthnRequest>, then it (the SP) 
better make sure those 'devices' are well-informed, 
-structured.

Or did I not catch the thrust of your formulation, below?

--Nick 

> -----Original Message-----
> From: Thomas Wisniewski [mailto:Thomas.Wisniewski@entrust.com] 
> Sent: Thursday, June 23, 2005 08:13 AM
> To: Nick Ragouzis; Thomas Wisniewski; 'Greg Whitehead'; 'Scott Cantor'
> Cc: 'SAML'
> Subject: RE: [security-services] ECP SSO Profile and Metadata
> 
> 
> Nick, I follow your reasoning here (and Scott's email 
> indicating the the SP usually identifies the ACS by index, etc...). 
> 
> So for the case where the SP selects an index for the ACS of 
> x, where x is not SOAP (e.g., HTTP-Post or HTTP-Artifact) or 
> if the SP did not specify an ACSUrl in AuthnRequest and the 
> default ACS endpoint in the SP's metadata that the IDP is 
> using is not SOAP, then:
> 
> The IDP has at least two paths it can follow: 
> 
> 1. Realize the input binding used was SOAP (and understand 
> this is an ECP type of SSO request). Therefore, it would 
> realize the index given for or the default ACS is incorrect. 
> And therefore respond with a SAML error Response (of course 
> it would probably look up a SOAP binding ACS - not sure what 
> to do if one is not found -- perhaps use (2)).
> 
> 2. Irregardless of the input binding used being SOAP, since 
> the ACS asked for is of another binding type, respond 
> appropriate for that binding. So this means HTTP-Post (send 
> the Response in the POST), or HTTP-Artifact  (send a 302 
> redirection with SAMLart).
> 
> 
> I believe option 1 is the correct approach (but the SOAP 
> binding must be there). Otherwise a soap fault or HTTP 403. 
> 
> Tom. 
> 
> > -----Original Message----- 
> > From: Nick Ragouzis [mailto:nickr@enosis.com] 
> > Sent: Thursday, June 23, 2005 10:48 AM 
> > To: 'Thomas Wisniewski'; 'Greg Whitehead'; 'Scott Cantor' 
> > Cc: 'SAML' 
> > Subject: RE: [security-services] ECP SSO Profile and Metadata 
> > 
> > 
> > I'm wondering about a couple of things here: 
> > 
> > 1. Greg's proposed that the IDP ep might be "bindings:SOAP-ECP" 
> >    to signal that this is a port that one can expect to receive 
> >    non-SOAP payloads back from in your http response. (As he's 
> >    just responded.) 
> > 
> >    Perhaps an ECP would optimize on that, but I suspect the 
> >    usual optimization would be to set up and initiate that 
> >    soap-http (https) request and to process that exchange just 
> >    as if you were in any other authentication request protocol 
> >    exchange ... where the IDP can conduct an exchange before 
> >    returning the <Response>, in this case the ecp:Response. 
> >    In this case, tho', the format of the payload will change. 
> > 
> >    Still, it has advantages: 
> >    a. It signals implementers of the difference, and 
> >    b. It gives implementers the machinery necessary to make and 
> >       activate the optimizations they desire, and 
> >    c. It deals now with something that would be complicated later 
> >       should someone want a new SOAP-type binding (a bit 
> >       oblique, I admit). 
> > 
> > 2. Isn't there some power/utility in leaving the SP-end of this 
> >    as is? I agree it's a pretty sensible thing to use 
> > "bindings:PAOS". 
> >    But the change from ID-FF1.2 present a useful loosening of the 
> >    coupling. 
> > 
> >    Now, in the ECP case, the /paos:Request/@responseconsumerURL 
> >    has two required uses, and no more: 
> > 
> >    a. The correlator/verifier with the /ecp:Response/ACSURL 
> >    b. The ep the SP wishes the ECP to use in reporting errors 
> > 
> >    So, if we don't change it, that 
> /paos:Request/@responseconsumerURL 
> >    *can* be something else, even a binding we've not yet defined. 
> >    The only requirement is *if* the SP is going to leave the IDP 
> >    to its own devices (e.g., metadata; i.e., not put ACSURL in the 
> >    <AuthnRequest>) then the SP had better make sure the IDP will 
> >    discover the same ep (loc:bind). In which case, the IDP (as one 
> >    example) should NOT be triggering/qualifying that on PAOS or 
> >    any other binding ... it just uses whatever comes up default 
> >    in metadata (e.g.). 
> > 
> > --Nick 
> > 
> > 
> > > -----Original Message----- 
> > > From: Thomas Wisniewski [mailto:Thomas.Wisniewski@entrust.com] 
> > > Sent: Thursday, June 23, 2005 05:05 AM 
> > > To: Greg Whitehead; Scott Cantor 
> > > Cc: 'SAML'; Thomas Wisniewski 
> > > Subject: 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. 
> > > 
> > > 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_workgr 
> > > oups.php 
> > > > 
> > > 
> > > 
> > 
> 
>