SAML: Web-Browser SSO Profile

Posted on by Ganesh Sivam

Refer SAML: Introduction before continuing this blog.

  • Web-Browser SSO Profile is a use-case, where user achieves single sign-on in a web-browser after successful authentication at IdP and without additional authentication, he/ she can access resources at any different SPs.
  • This is an important use case of SAML and widely used in the enterprise deployments.
  • Web Browser SSO profile supports two SSO methods:
    • SP Initiated SSO 
      • SSO flow initiated at the SP side (Pull method) and assertion received a.
      • Flow starts at SP, then to IdP and finally reaches SP. (i.e., SP -> IdP -> SP).
    • IdP Initiated SSO 
      • SSO flow initiated at the IdP side (Push method).
      • Flow starts at IdP, then pushes the assertion to SP (i.e., (IdP -> SP).
  • SSO Methods uses Request/Response style and has specific protocols to communicate between IdP and SP.
  • Due to two SSO methods and various SAML binding, there are various options available for Web-Browser SSO Profile (Request/Response style). They are:
    1. SP Initiated SSO:
      1. POST->POST binding
      2. Redirect->POST binding
      3. Artifact->POST binding
      4. POST->Artifact binding
      5. Redirect->Artifact binding
      6. Artifact->Artifact binding
    2. IdP Initiated SSO:
      1. POST binding
      2. Artifact binding
    3. ECP Profile
      1. PAOS binding

1. SP Initiated SSO

The following are the SP-initiated SSO flows which are based on binding (transport of SAML Request/ Response).

1.1. POST->POST binding

In this use case the user attempts to access a resource on http://www.abc.com. However they do not have current logon session on this site and their identity is managed by http://www.xyz.com. A SAML <AuthnRequest> is sent to their Identity Provider so that the Identity Provider can provide back a SAML assertion concerning the user. HTTP POST messages are used to deliver the SAML <AuthnRequest> to the Identity Provider as well as receive back the SAML response.

sp-init-1

  1. The user attempt to access a resource on http://www.abc.com. The user does not have any current logon session (i.e. security context) on this site, and is unknown to it.
  2. The SP sends a HTML form back to the browser. The HTML FORM contains a SAML <AuthnRequest> defining the user for which authentication and authorization information is required. Typically the HTML FORM will contain an input or submit action that will result in a HTTP POST.
  3. The browser, either due to a user action or via an “auto-submit”, issues a HTTP POST containing the SAML <AuthnRequest> to the IdP’s Single Sign-On service.
  4. If the user does not have any current security context on the IdP, or the policy defines that authentication is required, they user will be challenged to provide valid credentials.
  5. The user provides valid credentials and a security context is created for the user.
  6. The Single Sign-On Service sends a HTML form back to the browser. The HTML FORM contains a SAML <Response>, within which is a SAML assertion. The SAML specifications mandate that the response must be digitally signed. Typically the HTML FORM will contain an input or submit action that will result in a HTTP POST.
  7. The browser, either due to a user action or via an “auto-submit”, issues a HTTP POST containing the SAML response to be sent to the Service Provider’s Assertion Consumer service.
  8. The Service Provider’s Assertion Consumer validates the digital signature on the SAML Response. If this validates correctly, it sends a HTTP redirect to the browser causing it to access the TARGET resource, with a cookie that identifies the local session. An access check is then made to establish whether the user has the correct authorization to access the http://www.abc.com web site and the TARGET resource. The TARGET resource is then returned to the browser.

1.2. Redirect->POST binding

A SAML <AuthnRequest> is sent to their IdP so that the IdP can provide back a SAML assertion concerning the user. A HTTP redirect message is used to deliver the SAML <AuthnRequest> to the Identity Provider and a HTTP POST is used to return the SAML response.

sp-init-2

  1. The user attempt to access a resource on http://www.abc.com. The user does not have any current logon session (i.e. security context) on this site, and is unknown to it.
  2. The SP sends a redirect message to the browser with HTTP status code of either 302 or 303. The Location HTTP header contains the destination URI of the Sign-On Service of the Identity Provider together with the <AuthnRequest> as a query variable named SAMLRequest. The query string is encoded using the DEFLATE encoding. The browser processes the redirect message and issues a GET to the Sign-on Service with the SAMLRequest query parameter.
  3. The Sign-on Service determines whether the user has any current security context on the Identity Provider, or that the policy defines that authentication is required. If the user requires to be authenticated he will be challenged to provide valid credentials.
  4. The user provides valid credentials and a security context is created for the user.
  5. The Single Sign-On Service sends a HTML form back to the browser. The HTML FORM contains a SAML response, within which is a SAML assertion. The SAML specifications mandate that the response must be digitally signed. Typically the HTML FORM will contain an input or submit action that will result in a HTTP POST.
  6. The browser, either due to a user action or via an “auto-submit”, issues a HTTP POST containing the SAML response to be sent to the Service Provider’s Assertion Consumer service.
  7. The Service Provider’s Assertion Consumer validates the digital signature on the SAML Response. If this validates correctly, it sends a HTTP redirect to the browser causing it to access the TARGET resource, with a cookie that identifies the local session. An access check is then made to establish whether the user has the correct authorization to access the http://www.abc.com web site and the TARGET resource. The TARGET resource is then returned to the browser.

1.3. Artifact->POST binding

A SAML artifact is sent to the Identity Provider (using a HTTP redirect), which it uses to obtain a SAML <AuthRequest> from the Service Provider’s SAML Responder. When the Identity Provider obtains the SAML <AuthRequest> it provides back to the Service Provider the SAML response using the POST binding mechanism.

sp-init-3.png

  1. The user attempt to access a resource on http://www.abc.com. The user does not have any current logon session (i.e. security context) on this site, and is unknown to it.
  2. The SP generates the <AuthnRequest> while also creating an artifact. The artifact contains the source ID of the http://www.abc.com SAML responder together with a reference to the assertion (the AssertionHandle). The HTTP Artifact binding allows the choice of either HTTP redirection or a HTML form as the delivery mechanism to the Service Provider. The figure shows the use of the HTML form mechanism. The Inter-site Transfer Service sends a HTML form back to the browser. The HTML FORM contains the SAML artifact, the control name being SAMLart. Typically the HTML FORM will contain an input or submit action that will result in a HTTP POST.
  3. On receiving the HTTP message, the Single Sign-On Service, extracts the source-ID from the SAML artifact. A mapping between source IDs and remote Responders will already have been established administratively. The Assertion Consumer will therefore know that it has to contact the http://www.abc.com SAML responder at the prescribed URL. It sends the SAML <ArtifactResolve> message to the Service Provider’s SAML responder containing the artifact supplied by its Inter-site Transfer Service.
  4. The SAML responder supplies back a SAML <ArtifactResponse> message containing the <AuthnRequest> previously generated.
  5. The Sign-on Service determines whether the user, for which the <AuthnRequest> pertains, has any current security context on the Identity Provider, or that the policy defines that authentication is required. If the user requires to be authenticated he will be challenged to provide valid credentials.
  6. The user provides valid credentials and a security context is created for the user.
  7. The Single Sign-On Service sends a HTML form back to the browser. The HTML FORM contains a SAML response, within which is a SAML assertion. The SAML specifications mandate that the response must be digitally signed. Typically the HTML FORM will contain an input or submit action that will result in a HTTP POST.
  8. The browser, either due to a user action or via an “auto-submit”, issues a HTTP POST containing the SAML response to be sent to the Service Provider’s Assertion Consumer service.
  9. The Service Provider’s Assertion Consumer validates the digital signature on the SAML Response. If this validates correctly, it sends a HTTP redirect to the browser causing it to access the TARGET resource, with a cookie that identifies the local session. An access check is then made to establish whether the user has the correct authorization to access the http://www.abc.com web site and the TARGET resource. The TARGET resource is then returned to the browser.

1.4. POST->Artifact binding

A SAML <AuthnRequest> is sent to their Identity Provider so that the Identity Provider can provide back a SAML assertion concerning the user. A HTTP POST message is used to deliver the SAML <AuthRequest> to the Identity Provider. The response is in the form of a SAML Artifact. In this example the SAML Artifact is provided back within a HTTP POST message. The Service Provider uses the SAML artifact to obtain the SAML response (containing the SAML assertion) from the Identity Provider’s SAML Responder.

sp-init-4

  1. The user attempt to access a resource on http://www.abc.com. The user does not have any current logon session (i.e. security context) on this site, and is unknown to it.
  2. The SP sends a HTML form back to the browser. The HTML FORM contains a SAML <AuthnRequest> defining the user for which authentication and authorization information is required. Typically the HTML FORM will contain an input or submit action that will result in a HTTP POST.
  3. The browser, either due to a user action or via an “auto-submit”, issues a HTTP POST containing the SAML <AuthnRequest> to the Identity Provider’s Single Sign-On service.
  4. If the user does not have any current security context on the Identity Provider, or the policy defines that authentication is required, they user will be challenged to provide valid credentials.
  5. The user provides valid credentials and a security context is created for the user.
  6. The Single Sign-On Service generates an assertion for the user while also creating an artifact. The artifact contains the source ID of the http://www.xyz.com SAML responder together with a reference to the assertion (the AssertionHandle). The HTTP Artifact binding allows the choice of either HTTP redirection or a HTML form as the delivery mechanism to the Service Provider. The figure shows the use of the HTML form mechanism. The Single Sign-On Service sends a HTML form back to the browser. The HTML FORM contains the SAML artifact, the control name being SAMLart. Typically the HTML FORM will contain an input or submit action that will result in a HTTP POST.
  7. On receiving the HTTP message, the Assertion Consumer Service, extracts the source-ID from the SAML artifact. A mapping between source IDs and remote Responders will already have been established administratively. The Assertion Consumer will therefore know that it has to contact the http://www.xyz.com SAML responder at the prescribed URL.
  8. The http://www.abc.com Assertion Consumer will send a SAML <ArtifactResolve> message to the Identity Provider’s SAML responder containing the artifact supplied by the Identity Provider.
  9. The SAML responder supplies back a SAML <ArtifactResponse> message containing the assertion previously generated. In most implementations, if a valid assertion is received back, then a session on http://www.abc.com is established for the user (the relying party) at this point.
  10. Typically the Assertion Consumer then sends a redirection message containing a cookie back to the browser. The cookie identifies the session. The browser then processes the redirect message and issues a HTTP GET to the TARGET resource on http://www.abc.com. The GET message contains the cookie supplied back by the Assertion Consumer . An access check is then back to established whether the user has the correct authorization to access the http://www.abc.com web site and the index.asp resource.

1.5. Redirect->Artifact binding

Similarly there is a Redirect-> Artifact binding flow.

sp-init-5

1.6. Artifact->Artifact binding

Similarly there is a Artifact -> Artifact binding flow.sp-init-6.png

 

 

 

 

 

 

 

 

 

2. IdP Initiated SSO

The following are the IdP-initiated SSO flows which are based on binding (transport of SAML Request/ Response).

2.1. POST binding

In this use case the user has a security context on the Identity Provider and wishes to access a resource on a remote server (www.abc.com). The SAML assertion is transported to the Service Provider using the POST binding.

idp-init-1.png

  1. At some point the user will have been challenged to supply their credentials to the site http://www.xyz.com.
  2. The user successfully provides their credentials and has a security context with the Identity Provider.
  3. The user selects a menu option (or function) on the displayed screen that means the user wants to access a resource or application on another web site http://www.xyz.com.
  4. The SP sends a HTML form back to the browser. The HTML FORM contains a SAML response, within which is a SAML assertion. The SAML specifications mandate that the response must be digitally signed. Typically the HTML FORM will contain an input or submit action that will result in a HTTP POST.
  5. The browser, either due to a user action or via an “auto-submit”, issues a HTTP POST containing the SAML response to be sent to the Service provider’ Assertion Consumer service.
  6. The Service Provider’s Assertion Consumer validates the digital signature on the SAML Response. If this validates correctly, it sends a HTTP redirect to the browser causing it to access the TARGET resource, withing with a cookie that identifies the local session. An access check is then made to establish whether the user has the correct authorization to access the http://www.abc.com web site and the TARGET resource. The TARGET resource is then returned to the browser.

2.2. Artifact binding

In this use case the user has a security context on the Identity Provider and wishes to access a resource on a remote server (www.abc.com). An artifact is provided to the Service Provider, which its can use (that is “de-reference”) to obtain the associated SAML response from the Identity Provider.

idp-init-2.png

  1. At some point the user will have been challenged to supply their credentials to the site http://www.xyz.com.
  2. The user successfully provides their credentials and has a security context with the Identity Provider.
  3. The user selects a menu option (or function) on the displayed screen that means the user wants to access a resource or application on a destination web site http://www.abc.com .
  4. The IdP generates an assertion for the user while also creating an artifact. The artifact contains the source ID of the http://www.xyz.com SAML responder together with a reference to the assertion (the AssertionHandle). The HTTP Artifact binding allows the choice of either HTTP redirection or a HTML form as the delivery mechanism to the Service Provider. The figure shows the use of the HTML form mechanism. The Inter-site Transfer Service sends a HTML form back to the browser. The HTML FORM contains the SAML artifact, the control name being SAMLart. Typically the HTML FORM will contain an input or submit action that will result in a HTTP POST.
  5. On receiving the HTTP message, the Assertion Consumer Service, extracts the source-ID from the SAML artifact. A mapping between source IDs and remote Responders will already have been established administratively. The Assertion Consumer will therefore know that it has to contact the http://www.xyz.com SAML responder at the prescribed URL.
  6. The http://www.abc.com Assertion Consumer will send a SAML <ArtifactResolve> message to the Identity Provider’s SAML responder containing the artifact supplied by its Inter-site Transfer Service.
  7. The SAML responder supplies back a SAML <ArtifactResponse> message containing the assertion previously generated. In most implementations, if a valid assertion is received back, then a session on http://www.abc.com is established for the user (the relying party) at this point.
  8. Typically the Assertion Consumer then sends a redirection message containing a cookie back to the browser. The cookie identifies the session. The browser then processes the redirect message and issues a HTTP GET to the TARGET resource on http://www.abc.com. The GET message contains the cookie supplied back by the Assertion Consumer . An access check is then back to established whether the user has the correct authorization to access the http://www.abc.com web site and the index.jsp resource.

3. ECP Profile

The Enhanced Client and Proxy (ECP) Profile supports several use cases, in particular:

  • Use of a proxy server, for example a WAP gateway in front of a mobile device which has limited functionality.
  • Clients where it is impossible to use redirects.
  • It is impossible for the Identity Provider and Service Provider to directly communicate (and hence the HTTP Artifact binding can not be used).

3.1. PAOS binding

The ECP profile defines a single binding – PAOS (Reserve SOAP). The Profile uses both HTTP  and SOAP headers & bodies to transport SAML <AuthnRequest> and SAML <Response> messages between the Service Provider and the Identity Provider.

ecp

  1. The ECP wishes to gain access to a resource on the Service Provider (www.abc.com). The ECP will issue a HTTP request for the resource. The HTTP request contains a PAOS HTTP header defining that the ECP service is to be used.
  2. Accessing the resource requires that the principal has a valid security context, and hence a SAML assertion needs to be supplied to the Service Provider. In the HTTP response to the ECP an <AuthnRequest> is carried within a SOAP body. Additional information, using the PAOS binding, is provided back to the ECP
  3. After some processing in the ECP the <AuthnRequest> is sent to the appropriate Identity Provider using the SAML SOAP binding.
  4. The Identity Provider validates the <AuthnRequest> and sends back to the ECP a SAML <Response>, again using the SAML SOAP binding.
  5. The ECP extracts the <Response> and forwards it to the Service Provider as a PAOS response.
  6. The Service Provider sends to the ECP a HTTP response containing the resource originally requested.

Published by Ganesh Sivam

Leave a comment