+xHi Fabio, The call to SAMLServiceProvider.InitiateSSO creates and sends a SAML authn request to the IdP. By default we use the HTTP-Redirect binding which means a 302 HTTP response is returned to the browser which then redirects to the IdP with the authn request encoded as a SAMLRequest query string parameter. There is no direct communications between the IdP and SP sites. All messages are sent via the browser. If you use the browser developer tools (F12) to take a look at the network traffic you'll see how this flow works. oh ok! that's much more clear! thank for the clarification. So the flow is something like: 1- browser calls the sp to get the resource 2- sp creates the authn request and send it back to the browser in http redirect binding 3- the browser is redirected to the IdP bringing the authn request (GET) 4- IdP creates the response and sends it back in POST to the browser 5- browser passes the request to the ACS which parses it and proceeds to the resource Is it correct? We are trying to deploy our sp, which uses your component, to a complicated production environment so we need to be quite sure about what we are doing. Unfortunately not all the technical aspect of the protocol implementation are so clear to me. You said that by default you use a HTTP Redirect Binding to pass the authn request to the browser, can this behavior be changed? thank you again, Fabio
|