JumpCloud and Identity Provider (IdP) - Quick Start



User experience begins with sign-in process. In today’s digital world we use many applications (at our workplace and outside). Remembering passwords and/or reauthenticating every time we access these applications within same provider ecosystems is not a desirable user experience. 

Many of us use google applications (Gmail, Google drive, YouTube etc.) and if you must sign-in again-and-again to access these applications then I am sure you’ll not be very happy. And yes, there is a chance that you may forget password as well.

At your workplace you may have timesheet application, payroll application and many other. If you sign-in only once and can access all other application without having to sign-in again then you are lucky, SSO implemented at your workplace.

In this article we’ll look at detailed steps to create SSO (Identity Provider i.e., IdP) application on JumpCloud. The IdP application can be used as an Identity Provider (IdP) to implement SSO with any other Service Provider (SP) application.

 

What is Single Sign-On?

Single Sign-On allows users to authenticated themselves once and auto-login to multiple applications (that talks to same identity provider) without reauthenticating. If you are not sure what is Identity Provider (IdP), stay with me, I’ll cover that later shortly.

Here are key terms that you should be aware of while learning about Single Sign-On (SSO):

  • Identity/principal – this is the actual user (credentials) in a database (e.g., an Active Directory)
  • Identity Provider (IdP) - An identity provider is a system entity that creates, maintains, and manages identity/authentication information for principals and also provides authentication services to reliant applications within a federation or distributed network. Identity providers offer user authentication as a service. In this article, we’ll use JumpCloud as our Identity Provider (IdP)
  • Service Provider - A Service Provider (SP) is the entity providing the service, typically in the form of an application. In this article, AEM is our Service Provider.
  • Trust Store/Signing Certificate - SSO works based upon a trust relationship set up between Service Provider (SP) like AEM, and an identity provider (IdP), like JumpCloud. This trust relationship is often based upon a certificate that is exchanged between the identity provider and the service provider. This certificate can be used to sign identity information that is being sent from the identity provider to the service provider so that the service provider knows it is coming from a trusted source.
  • Security Assertion Markup Language (SAML) – it is an XML based open standard to exchange authentication information between Identity Provider (IdP) and Service Provider (SP). SAML request and response entities must follow defined standards while exchanging information.

SSO Authentication can be initiated by Identity Provider (IdP-initiated) or Service Provider (SP-initiated).

  • A Service Provider Initiated (SP-initiated) sign-in is initiated by the Service Provider. This is typically triggered when the end user tries to access a resource or sign in directly on the Service Provider side, such as when the browser tries to access a protected resource on the Service Provider side.
  • An Identity Provider Initiated (IdP-initiated) sign-in is initiated by the Identity Provider. Instead of the SAML flow being triggered by a redirection from the Service Provider, in this flow the Identity Provider initiates a SAML Response that is redirected to the Service Provider to assert the user's identity.

 

Refer this article to learn about how you can use JumpCloud as Identity Provider with AEM:

https://suryakand-shinde.blogspot.com/2022/02/aem-single-sign-on-sso-using-jumpcloud.html


How Single Sign-On (SSO) works?

The login flow usually looks like this:

 

Graphical user interface, application

Description automatically generated

  1. A user tries to access a secured resource (web page, video etc.) on Service Provider (SP) site
  2. The Service Provider sends a token that contains some information about the user, like their email address, to the Identity Provider, as part of a request to authenticate the user.
  3. The Identity Provider first checks to see whether the user has already been authenticated, in which case it will grant the user access to the Service Provider application and skip to step E.
  4. If the user hasn’t logged in, the user will be prompted to do so by providing the credentials required by the Identity Provider. This could simply be a username and password, or it might include some other form of authentication like a One-Time Password (OTP).
  5. Once the Identity Provider validates the credentials provided, it will send a token back to the Service Provider confirming a successful authentication.
  6. This token is passed through the user’s browser to the Service Provider.
  7. The token that is received by the Service Provider is validated using the trust relationship that was set up between the Service Provider and the Identity Provider during the initial configuration.
  8. The user is granted access to the Service Provider

There are 3 main steps involved:

  1. Create a JumpCloud account
  2. Create User Group and few User accounts for testing
  3. Create SSO (Identity Provider) application 

Step 1: Create a JumpCloud account

  • You can create an account by navigating to https://jumpcloud.com/pricing. There are both (trail and paid) options available. For this article any one of those will work.


Step 2: Create User Group and User accounts

  • Create a user group (e.g., “AEM Administrator”)

 

Graphical user interface, application

Description automatically generated

  • Create a user and add it to “AEM administrator” group create in previous step

 

Graphical user interface, application, Teams

Description automatically generated

Step 3: Create SSO (Identity Provider) application 

Graphical user interface, application, Teams

Description automatically generated

  • Click on “Custom SAML app”

Graphical user interface, application

Description automatically generated

  • Provide a name for your application (e.g., AEM Local)

Graphical user interface, text, application

Description automatically generated

  • Click on “SSO” Tab. Fill in the details as follows and click on “activate” button on right-bottom corner

Graphical user interface, application, Teams

Description automatically generated

  • If there is a need to add custom attributes to user account, we can do that as well using Service Provider Attribute Name

Graphical user interface, application, Teams

Description automatically generated

  • Once SSO application is activated, we need to download the certificate from JumpCloud and import it in Service Provider application (e.g., AEM). Go to the newly created SSO app and download certificate

Graphical user interface, text, application, email

Description automatically generated

 

At this point we are done with creating an SSO application in JumpCloud. We also have required certificate that we could use to configure Service Provider application.

Refer this article to learn about how you can use JumpCloud as Identity Provider with AEM (as a Service Provider):

https://suryakand-shinde.blogspot.com/2022/02/aem-single-sign-on-sso-using-jumpcloud.html

I hope you have gained good understanding of SSO and how you can use JumpCloud for quick integration.

Feel free to comment if you have any question or suggestions.

Comments

Popular posts from this blog

AEM as a Cloud Service (AEMaaCS) – Architecture Overview

Custom synchronisation or rollout action for blueprint ?

AEM as a Cloud Service (AEMaaCS) – Quick Introduction

AEM - Query list of components and templates