RE: [saml-dev] Use of ECP Profile

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

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

[Jean-Noel Colin] 

Couldn't SPA act as a proxy to SPB? In this particular case, SPA, acting as a ECP to SPB, would invoke SPB, get an AuthnRequest from SPB, and since it is not able to authenticate the user (as it is not a 'full' IdP), would relay the request to the original ECP, which knows which IdP to use.

 

I drew a sequence diagram that I attach. Could you please tell me what's wrong with it?

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

[Jean-Noel Colin]   I guess you call 'token' an Authentication Assertion?

So when SPA wants to invoke another service, it requests a token from the IdP (how does it know the IdP? From the response he got from the ECP?) and include that token in its request to SPB?

What would be the added value of the Disco Service from WSF? I understood it as a directory of services? Do you mean that that directory service could be used to indicate which requirements apply to SPB, so that when SPA wants to invoke SPB, it knows which type of token to include? Does this refer to the SecurityMechID element of the Service Instance Description?

 

Thanks a lot

 

Jean-Noel

 

Proxying.jpg