saml-dev message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [saml-dev] Use of ECP Profile
- From: "Jean-Noel Colin" <jean-noel.colin@oxys.be>
- To: "'Conor P. Cahill'" <concahill@aol.com>
- Date: Mon, 25 Oct 2004 15:30:45 +0200
My comments in the text below. Thanks
again
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]