RE: [saml-dev] Use of ECP Profile

["Conor P. Cahill" <concahill@aol.com>]

Jean-Noel Colin wrote on 10/26/2004, 8:48 AM:

Conor,

 

What do you mean by ' broser/ECP you have to pass control of the user (via re-direct) to the other service.'? What is 'control of the user'? The way I understood the profile was that when the ECP receives an AuthnRequest from the SP, it simply forwards it to the IdP, that if necessary, interacts with the user to establish a security context, and then replies with Authn Assertions. As all exchanges between modules are SOAP based, I guess we can pass whatever content we want in the messages, can't we?

Almost.   The key
is that when you send the soap message to  the IdP from the ECP, the
expectation is that the user is sitting in front of the ECP so that if
the IdP needs to prompt for credentials, it simply returns to the ECP
the login form for the user.    The IdP also gets any cookies it has
stored on the ECP so that, should it have stored a session ID in a
cookie in the ECP and the session is still valid, it won't have to
prompt the user for credentials.

This works fine in the first step of your model, when the user comes to
SP-A since the user is in front of the ECP talking to SP-A.  However,
when SP-A, acting as an ECP goes to SP-B, the user is no longer in
front of the ECP and any cookies the IdP may have stored in the real
ECP are not available.

To do this right with SAML, SPA needs to redirect the user's real ECP
to SP-B (thereby loosing direct control of the user).

In any case, I don't want the SP to interact with the user directly or handle UI to authenticate him.

So you can't act
as an ECP then.

I might have not been clear while explaining my architecture, so let me put a small picture:

So I think you
need at least an AuthenticationService interface to the IdP that let's
SP-A ask for a token for SP-B and then include that token as appopriate
on the call to SP-B.  This can be more complex than simply including a
token (hence the Discovery Service in ID-WSF).

Conor