Hello,
Snippetin your ExampleServiceProvider WebForms example code, in the login.aspx page after clicking the SSO button, then method SAMLServiceProvider.InitiateSSO is called to send the authn request to the IdP.
But in this way, the SP needs to reach the IdP which is against the SAML logic where only the browser reaches both of them (the SP and the IsP).
Where am i wrong?
thank you
Fabio
Hi 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.
[quote][/quote]
Hi 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.
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
The flow you listed is correct. You’ll find our SAML Primer, which provides an overview of the various SAML flows, at:
https://www.componentspace.com/Forums/9355/SAML-Primer
The other option for sending the SAML authn request is to use the HTTP-Post binding rather than the HTTP-Redirect binding. This is the same binding used by the IdP to send the SAML response.
By default we use HTTP-Redirect but you can specify in your SAML configuration to use HTTP-Post. For example:
<PartnerIdentityProvider
Name=“<a href=“https://ExampleIdentityProvider””>https://ExampleIdentityProvider"
SignAuthnRequest=“true”
SingleSignOnServiceBinding=“urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST”
SingleSignOnServiceUrl=“<a href=“https://localhost:44390/SAML/SSOService.aspx””>https://localhost:44390/SAML/SSOService.aspx"
SingleLogoutServiceUrl=“”>https://localhost:44390/SAML/SLOService.aspx">