SSO
      Back to home
      1. Help Center
      2. SSO
      3. SSO

      Introduction to SSO

      What is SSO?

      Single sign-on (or SSO) is an authentication way and helps to log in to an application with just a single set of credentials, rather than setting up multiple usernames and passwords across different platforms.

      SAML is an open standard for allowing single sign-on between 2 systems: A Service Provider (HackerEarth) and an Identity Provider (the system storing your organization's user database e.g. Okta, OneLogin, etc.).

      SAML or Security Assertion Markup Language is an open standard that is used to exchange authentication and authorization data between two parties.

      Identity Provider (IdP)

      The system is responsible for user authentication and plans the single sign on between multiple applications. For example, accounts.google.com is an IdP.

      Service Provider

      This system provides a service to the users who are logged in via an IdP. For example, YouTube, Gmail, etc.

      SAML

      At HackerEarth, we use the SAML protocol for SSO, which means that we can only cater to those clients whose IdP supports SAML.

      SSO

      From a user’s perspective, the lifecycle for logging in when a user comes to the HackerEarth tenant is as follows:

       

       

      Security measures

      We have security measures in place at each step.

       

      Pre-context

      All our services operate using the HTTPS protocol which means that all the data that is exchanged in the interservice or service to user communication is encrypted.

      1. User accesses toggle.hackerearth.com (there is no exchange of sensitive data)
      2. User clicks Login via SSO
      3. The user is redirected to HackerEarth Auth Service. With this redirect, we pass on the following:
      • Client information (in this case HackerEarth Sprint)
      • Callback URL (for redirection after the user is authenticated at the SSO provider)
      • Tenant identity as query params

      No sensitive data is exchanged here. The redirect URL is temporarily stored in auth service.

      1. Auth service creates a signed SAML request and redirects the user to the tenant's SSO provider’s predefined URL. Here, the signed SAML request is sent as a query param in the redirect request to a pre-configured URL of the IdP of the client.
      2. User login: In this step, information exchange takes place between the user and the client’s IdP directly.
      3. A signed SAML response is created and a POST request is sent. The SAML response is signed with the private key of the IdP and the request is sent over HTTPS which encrypts the data that is in transit. When the request is received by auth service, the signature of the POST data is verified to ensure that the data was not tampered with by an eavesdropper.
      4. Responds with the redirect URL for HackerEarth and the auth code as a query param in that redirect URL. At this step, auth service sends a 307 status response to the IdP with the location in the header so that the IdP redirects the user to the redirect URL from step 3. The response is over https too. Please note that an auth-code is added as a query param in the redirect URL.
      5. Redirects the user to a callback/redirect URL sent in the previous step. This redirect URL has an authcode in the query params. An eavesdropper in the middle can intercept the authcode but it is useless because it’s just a random key without any encrypted sensitive data.
      6. An API call is made to get JWT on the basis of the auth code. A POST request is sent to the auth service with the authcode in the POST data to get the JWT corresponding to this authcode. The request is made over HTTPS.
      7. The auth service responds with an encoded JWT token with a signature.
      8. The JWT that is received from the auth service is decoded and is validated against the signature to ensure that no in-transit tampering has happened and sets the token in the cookie and the user is logged in.

      Integrating the HackerEarth tenant with the client’s IdP

      At a basic level, the initial exchange of the configuration to register the IdP and SP with each other happens via XML documents. An example of this is integrating the HackerEarth tenant with the client’s IdP configuration is as follows:

       

      Identity Provider config

      Components

      1. SSO URL: The URL on which the user will be taken to on the IdP (SSP Provider) by the service provider when a user hits Log in via SSO on service provider. This supports 2 methods, POST API call or redirecting the user. Right now, we are supporting redirect. In the above config this URL can be found here:
        <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="<identity provider url>"/>
      2. Entity ID: An entity ID is a globally unique name for a SAML entity, either an Identity Provider (IdP) or a Service Provider (SP).

      <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="<entity id>" validUntil="2022-07-04T07:09:05.000Z">

       

      1. Certificate: A SAML entity uses public-key cryptography to secure the data transmitted to trusted partners. Public keys are published in the form of X.509 certificates in metadata whereas the corresponding private keys are held securely by the entity. These keys are used for message-level signing and encryption, and to create secure back channels for transporting SAML messages over TLS.