InApp   /   Our Leaders   /  

Everything About Single Sign On (SSO)

Everything About Single Sign On (SSO)

What do you mean by Single Sign On (SSO)?

  • Single sign-on is authentication to access the different applications from a single environment by without giving multiple usernames or passwords.
  • Single sign-on uses only one login and through this users access different applications.
  • Single sign-off, reverse action of SSO that single action of signing out terminates access of multiple applications.

SAML (Security Assertion Mark-up Language)

  • SAML is an XML standard that allows secure web domains to exchange user authentication and authorization data.
  • SSO authentication process only applies to the web-based application
  • For Windows, usable passwords and synchronize those passwords with your internal user database using the Provisioning API
  • Using SAML, an online service provider can contact a separate online identity provider to authenticate users who are trying to access secure content.

How SAML works in SSO

Let’s see how SAML works in SSO authentication.

Look at the workflow of SSO authentication used in the Google application.
Initially, before the whole process, the partner must provide Google with the URL for its SSO service as well as the public key that Google should use to verify SAML responses.

SAML

The following steps are the workflow of the entire SSO authentication process. Each step number is plotted in the above figure:

  1. The user attempts to reach a hosted Google application, such as Gmail, Start Pages, or another Google service.
  2. Google generates a SAML authentication request. The SAML request is encoded and embedded into the URL for the partner’s SSO service. The RelayState parameter containing the encoded URL of the Google application that the user is trying to reach is also embedded in the SSO URL. This RelayState parameter is meant to be an opaque identifier that is passed back without any modification or inspection.
  3. Google sends a redirect to the user’s browser. The redirect URL includes the encoded SAML authentication request that should be submitted to the partner’s SSO service.
  4. The partner decodes the SAML request and extracts the URL for both Google’s ACS (Assertion Consumer Service) and the user’s destination URL (RelayState parameter). The partner then authenticates the user. Partners could authenticate users by either asking for valid login credentials or by checking for valid session cookies.
  5. The partner generates a SAML response that contains the authenticated user’s username. In accordance with the SAML 2.0 specification, this response is digitally signed with the partner’s public and private DSA/RSA keys.
  6. The partner encodes the SAML response and the RelayState parameter and returns that information to the user’s browser. The partner provides a mechanism so that the browser can forward that information to Google’s ACS. For example, the partner could embed the SAML response and destination URL in a form and provide a button that the user can click to submit the form to Google. The partner could also include JavaScript on the page that automatically submits the form to Google.
  7. Google’s ACS verifies the SAML response using the partner’s public key. If the response is successfully verified, ACS redirects the user to the destination URL.
  8. The user has been redirected to the destination URL and is logged in to Google Apps.

These are the basic principle behind the working of SSO authentication.

Advantages of SSO applications

  • Reduces phishing success, because users are not trained to enter passwords everywhere without thinking.
  • Reducing password fatigue from the different user names and password combinations
  • Reducing time spent re-entering passwords for the same identity
  • Can support conventional authentication such as Windows credentials (i.e., username/password)
  • Reducing IT costs due to a lower number of IT help desk calls about passwords
  • Security on all levels of entry/exit/access to systems without the inconvenience of re-promoting users
  • Centralized reporting for compliance adherence.

Criticisms

  • SSO servers can introduce a single point of network failure.
  • The SSO server and other host security must be hardened

What is the area that needs to be tested in SSO authentication applications

  • Check Browser Cache
  • Check authenticated and non-authenticated users
  • Check users have different privileges
  • Check URL security
  • Check server performances

Basic Test Scenarios for SSO Login Authentication:

1. Valid users logged in to their own intranet application and accessed external host application
Result:- Users should be able to access external host applications since they are valid sso users.

2. Invalid users logged in to their own intranet application and access the external host application
Result:- External application login prompt should show up since they are invalid sso users.

3. Valid user logged in intranet and accessed the external host application and at the same time intranet session expires
Result: The user should be able to work on an external host application even if the intranet session expires.

4. Valid user logged in to intranet, accessed an external application and logged out, and again access an external application
Result:- The user should be logged in to the external application without a login prompt.

5. Valid user logged in to intranet, accessed external application, and then session out from innotas application
Result:- The user should be able to continue working on the external application after expires since a session has already been made with the intranet application, so while the session is out user credentials will be automatically fetched from the browser cache and logged in.

Have questions? Contact the technology experts at InApp to learn more.