RE: [saml-dev] Use of ECP Profile

["Jean-Noel Colin" <jean-noel.colin@oxys.be>]

My comments in the text below. Thanks again

---

From: Conor P. Cahill [mailto:concahill@aol.com]
Sent: lundi 25 octobre 2004 14:21
To: Jean-Noel Colin
Cc: saml-dev@lists.oasis-open.org
Subject: RE: [saml-dev] Use of ECP Profile

Jean-Noel Colin wrote on 10/25/2004, 8:08 AM:

Regarding the use of ECP, I fully agree that a SP does not have to know where the IdP is, but as in my case, a SP may also be a ECP (in case of service chain), it means that each SP in the chain has to know which IdP to use, or that this information is carried in the request for service.

if SPA is acting as ECP to another SP (say SP-B), then SP-A would indicate that it is an ECP in the HTTP headers so that SP-B would send the request to the SP-A ECP which would then know where  the IdP is.

[Jean-Noel Colin] what if SP-A can't act as ECP because it does not know which IdP to use? Could it then act as a proxy, so that it would appear as the IdP to SP-B, but in fact resend the AuthnReq to UE? So in a first step, UE invokes SP-A, which sends back an AuthnReq to UE which calls on the IdP... When later SP-A calls SP-B, SP-B sends the AuthnReq to SP-A, which sends it back to UE and we are back to the previous case. This would deal with arbitrarily long service chains. Do you see anything wrong with this? 

Regarding your suggestion of not using ECP, does this mean that SP-A would adjust the AssertionConsumerServiceURL attribute to point to SP-B? What would be the workflow?

My assumption was that SP-A would indicate that 
the request was initiated by SP-B (yes, a little white lie) and then the IdP 
would use the metadata service to locate the information for 
SP-B

To complete the request, SP-A needs to invoke a service from SP-B.

If SP-A submits an AuthnRequest to IdP for SP-B, if IdP sends the AuthnResponse to SP-B, SP-B does not know about the service that is being invoked (as SP-A did not issue the call)

You can place this information into the relay 
state area (yes both SP-A and SP-B have to agree on the format and contents, but 
that's simple enough.

If IdP sends the AuthnResponse to SP-A, this requires that SP-A is able to send this back to SP-B with the call parameters.

IdP should not send SP-B's 
AuthenResponse to SP-A (that would have bad privacy 
consequences).

What if we have an arbitrarily long chain? SP-B may in turn call SP-C which will call SP-D. In this case, how does SP-B know which IdP to contact?

SP-B gets an AuthnResponse that includes the identification of the IdP and can use this subseqently.

[Jean-Noel Colin] In this model, this means that SP-B receives an unsollicited AuthnResponse about a subject, but would not have received any prior service invocation. Does this mean that it would 'cache' the AuthnAssertions received, so that when SP-A invokes it, it already has an authentication context and is thus able to serve the request?

 

 
Note that for service to service calls, I don't recommend going through a browser (although it can work)... I'd recommend using some form of web services infrastructure that can go directly from service to service without involving the browser.  This is the kind of stuff we built into Liberty's Web Services Framework.

[Jean-Noel Colin] In fact, our whole model is not using browser, except as an entry point. All interaction beyong the user's main portal (what I called User ENvironmnent - UE before) is done through web services. And basically, what we want to achieve is that each service should authenticate the requester before actually serving any request.

 

Cheers,

 

Jean-Noel