[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [saml-dev] Use of ECP Profile
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.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?
So you can't act as an ECP then.In any case, I don't want the SP to interact with the user directly or handle UI to authenticate him.
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).I might have not been clear while explaining my architecture, so let me put a small picture:
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]