Single Sign-On and ADFS

What Is Single Sign-On

Single sign-on (SSO) is an authentication method that enables users to access multiple applications with one login and one set of credentials.

When you set up SSO, you configure one system to trust another to authenticate users, eliminating the need for users to log in to each system separately. The system that authenticates users is called an identity provider. The system that trusts the identity provider for authentication is called the service provider.

For example, you can configure Google as an identity provider to authenticate users accessing your org. So users login to your org using their Google credentials. In this example, your org acts as the service provider, trusting Google to accurately authenticate users.

You can also set up a single identity provider to authenticate users for multiple service providers. For example, you can enable your org as an identity provider and configure Office 365 and DevOps as service providers. Users can then access your org, Office 365, and DevOps with one login.

After you configure SSO, set up Single Logout so users can log out of a service provider and identity provider at the same time.

SSO Protocols: WS-Fed, SAML2 and OAuth/OpenID Connect

SAML and WS-Federation are two very popular protocols that allow users that have already logged into one site to access another site without logging in again. WS-Fed (WS-Federation) is a protocol from WS-* family primarily supported by IBM & Microsoft, while SAML (Security Assertion Markup Language) adopted by Computer Associates, Ping Identity and others for their SSO products. The premise with both WS-Fed and SAML is similar – decouple the applications (relying party / service provider) from identity provider. This decoupling allows multiple applications to use a single identity provider with a predefined protocol, and not care about the implementation details of identity provider per se.

For web applications, this works via a set of browser redirects and message exchanges. User tries to access web application, the application redirects user to identity provider. User authenticates himself, identity provider issues a claims token and redirects user back to the application. Application then validates the token (trust needs to established out of band between application and IdP), authorizes user access by asserting claims, and allows user to access protected resources. The token is then stored in the session cookie of user browser, ensuring the process doesn’t have be repeated for every access request.

OAuth 2.0 is a framework that controls authorization to a protected resource such as an application or a set of files, while OpenID Connect, like WS-FED and SAML,  is both industry standards for federated authentication. OpenID Connect is built on the OAuth 2.0 protocol and uses an additional JSON Web Token (JWT), called an ID token, to standardize areas that OAuth 2.0 leaves up to choice, such as scopes and endpoint discovery. It is specifically focused on user authentication and is widely used to enable user logins on consumer websites and mobile apps.

Single Sign-On (SSO) Authentication Flow

There ate two types of Single Sign-on (SSO) authentication flows:

• Service Provider initiated Single Sign-On (SSO) authentication flow
• Identity Provider initiated Single Sign-On (SSO) authentication flow

Service Provider initiated Single Sign-On authentication flow

1-The user attempts to access a resource on sp.example.com. The user does not have a valid logon session (i.e. security context) on this site. The SP saves the requested resource URL in local state information that can be saved across the web SSO exchange.

2-The SP sends an HTTP redirect response to the browser (HTTP status 302 or 303). The Location HTTP header contains the destination URI of the Sign-On Service at the identity provider together with auth resquest message.

3-The Single Sign-On Service determines whether the user has an existing logon security context at the identity provider that meets the default or requested (in the <AuthnRequest>) authentication policy requirements. If not, the IdP interacts with the browser to challenge the user to provide valid credentials.

4-The user provides valid credentials and a local logon security context is created for the user at the IdP.

5-The IdP Single Sign-On Service builds a SAML assertion representing the user's logon security context. Since a POST binding is going to be used, the assertion is digitally signed and then placed within a SAML <Response> message. The <Response> message is then placed within an HTML FORM as a hidden form control named SAMLResponse. If the IdP received a RelayState value from the SP, it must return it unmodified to the SP in a hidden form control named RelayState. The Single Sign-On Service sends the HTML form back to the browser in the HTTP response. For ease of use purposes, the HTML FORM typically will be accompanied by script code that will automatically post the form to the destination site.

6-The browser, due either to a user action or execution of an “auto-submit” script, issues an HTTP POST request to send the form to the SP's Assertion Consumer Service. The service provider's Assertion Consumer Service obtains the <Response> message from the HTML FORM for processing. The digital signature on the SAML assertion must first be validated and then the assertion contents are processed in order to create a local logon security context for the user at the SP. Once this completes, the SP retrieves the local state information indicated by the RelayState data to recall the originally-requested resource URL. It then sends an HTTP redirect response to the browser directing it to access the originally requested resource (not shown).

7-An access check is made to establish whether the user has the correct authorization to access the resource. If the access check passes, the resource is then returned to the browser.

Identity Provider initiated Single Sign-On (SSO) authentication flow

1-If the user does not have a valid local security context at the IdP, at some point the user will be challenged to supply their credentials to the IdP site, idp.example.org.

2-The user provides valid credentials and a local logon security context is created for the user at the IdP.

3-The user selects a menu option or link on the IdP to request access to an SP web site, sp.example.com. This causes the IdP's Single Sign-On Service to be called.

4-The Single Sign-On Service builds a SAML assertion representing the user's logon security context. Since a POST binding is going to be used, the assertion is digitally signed before it is placed within a SAML <Response> message. The <Response> message is then placed within an HTML FORM as a hidden form control named SAMLResponse. (If the convention for identifying a specific application resource at the SP is supported at the IdP and SP, the resource URL at the SP is also encoded into the form using a hidden form control named RelayState.) The Single Sign-On Service sends the HTML form back to the browser in the HTTP response. For ease-of-use purposes, the HTML FORM typically will contain script code that will automatically post the form to the destination site.

5-The browser, due either to a user action or execution of an “auto-submit” script, issues an HTTP POST request to send the form to the SP's Assertion Consumer Service. The service provider's Assertion Consumer Service obtains the <Response> message from the HTML FORM for processing. The digital signature on the SAML assertion must first be validated and then the assertion contents are processed in order to create a local logon security context for the user at the SP. Once this completes, the SP retrieves the RelayState data (if any) to determine the desired application resource URL and sends an HTTP redirect response to the browser directing it to access the requested resource (not shown).

6-An access check is made to establish whether the user has the correct authorization to access the resource. If the access check passes, the resource is then returned to the browser.