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


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



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