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.

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.

In this article we’ll look at detailed steps to configure AEM SSO authentication handler (which is a SAML based authentication handler).

How Single Sign-On (SSO) works?

The login flow usually looks like this:

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

Authentication options in AEM 

Let’s first look at various options available in AEM for configurating authentication.

AEM has a robust security implementation (based on Sling Authentication). The Sling Authentication is a complete framework, and it provides foundation for implementing different type of authentication schemes. AEM leverages Sling Authentication framework and support multiple authentication methods out-of-the-box (OOTB). Based on whether users are getting authenticated against the AEM user repository or an external identity provider we can divide the authentication implementation in 2 groups (as follows):

As we discussed above, we’ll be using a cloud-based directory service called as JumpCloud. You may want to create a free JumpCloud cloud account to follow along this tutorial.

Link to JumpCloud: https://jumpcloud.com/pricing

Prerequisites to follow this step-by-step tutorial:

• An AEM instance (let’s say author is running on http://localhost:4502/)
• JumpCloud account (either free/trail or paid)

There are 4 main steps to configure AEM SSO handler:

1. Configure Identity Provider (in this case JumpCloud SSO/SAML) to work with AEM. To do this, we need to create an SSO application on Identity Provider (IdP) and get the certificate and other details required to SSO handler in AEM
2. Create a Global Trust Store in AEM and import IdP certificate
3. Create Keystore for “authentication-service” user in AEM
4. Configure “Adobe Granite SAML 2.0 Authentication Handler”. We we’ll also create a user group in AEM (e.g., jumpcloud-sso) so that after successful SSO authentication users (from JumpCloud) will get added to this group.

Time for action! Let’s perform each of these steps one by one.

Step 1: Configure JumpCloud SSO/SAML to work with AEM

• Login to JumpCloud (please create an account first if you don’t have one): https://console.jumpcloud.com/login/admin
• Create a user group “AEM Administrator”

At this point we are done with creating an SSO application in JumpCloud. We also have required certificate that we’ll use in next step.

Step 2: Create a Global Trust Store in AEM and import IdP certificate

• In AEM, go to Tools > Security > Trust Store
• Click “Create Trust store” if one doesn’t exist already. Provide a password (in this case, I am going to use “admin”)
• Click “Select Certificate File”, upload certificate (downloaded from JumpCloud) and map it against a user. You can map it against any user because the Trust Store in AEM is Global
• Copy or make note of certificate alias, we would need it for SAML configuration in step 4 (later in this article)

Once everything is configured, you should have a screen as follows:

Step 3: Create Keystore for “authentication-service” user in AEM

• In AEM, Go to Tools > Security > Users
• Search for “authentication-service”
• Create keystore. Provide a password (e.g., admin). Make note of this password as we’ll need this password when we are configuring SAML authentication handler in Web/OSGi Console.

Step 4: Configure “Adobe Granite SAML 2.0 Authentication Handler”

• In AEM, go to Tools > Operations > Web Console
• Click to add a new config for “Adobe Granite SAML 2.0 Authentication Handler”
• Add the configurations gathered from JumpCloud (see screen shot below). The description about each field can be found on link. You can learn more about the configuration parameters here: https://experienceleague.adobe.com/docs/experience-manager-65/administering/security/saml-2-0-authenticationhandler.html

If you have followed the exact steps as outlined in this article then, you can use the values shown in above screen shot else adjust is based on actual values that you have used.

Important notes about SAML 2.0 Authentication Handler configuration:

• The “Path” configuration tells AEM at which path this SSO handler should be invoked. In this case when user will try to access http://localhost:4502/content/wknd-spa-angular.html the user will be redirect to IdP (JumpCloud) for authentication. This path can be any path under “/content” path of AEM.
• The “IDP Certificate Alias” is the value that we got in Step 2 (while configuring “Global Trust Store”)
• The “Service Provider ID” should match with the “SP Entity ID” that we have configured in JumpCloud while creating SSO application (see Step 1 above)
• The “Password of key store” is the password that we have provided while creating “Keystore” in previous step (I have used “admin” as password).
• The “UserID attribute” configuration instructs authentication handler to look for this attribute in IdP response to identify the authenticated user
• The “Synchronize Attributes” configuration mapping tells SSO authentication handler to map the attributes of JumpCloud user to AEM profile.

If you run into “Forbidden 403” error, please update “Apache Sling Referrer Filter” as follows:

At this point everything is configured, and it is time to do the test drive!

Let’s do a test:

• Navigate to http://localhost:4502/content/wknd-spa-angular.html (or to the path you have configured SSO authentication handler configuration)
• If user not authenticated already, JumpCloud will ask the user to enter credentials

I hope you have gained good understanding of SSO and how it works in AEM. 

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

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:

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

Step 2: Create User Group and User accounts

Step 3: Create SSO (Identity Provider) application 

• Login to JumpCloud (please create an account first if you don’t have one): https://console.jumpcloud.com/login/admin
• Navigate to SSO console for creating SSO application: https://console.jumpcloud.com/#/sso
• Click on “+” sign to create new SSO application

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.

Most organization want to keep content and user experience flexible so that they can innovate and deliver new experiences/features faster. Flexibility allows organizations to reuse what has been built already and keep adding new features and functionalities on top of it. One of the key characteristics of flexibility is backward compatibility and non-breaking changes.

This flexibility comes with a clear definition of a strategy for content creation and user experience.

In this article we are going to look at 2 very simple but powerful component development strategies that organization (specifically technical teams) can adopt to win the flexibility game and stay ahead in competition of delivering rich user experience.

Let’s start with a scenario/problem statement. 

Assume that a large banking organization has business in multiple countries. The organization is using AEM and MSM (Multi Site Manager) to manage regional sites. The bank started using a video component (custom developed) few years ago. The video component is integrated with Google analytics. The bank is starting business in few new countries and has decided to use Adobe analytics on new websites for video tracking.

The common considerations to implement such scenario:

• We need to ensure that existing component’s functionality (Google analytics) is not impacted
• We need to just update the tracking behaviour of component (ideally this can be achieved using a well-defined DataLayer and Tag management implementation, we’ll ignore DataLayer for now)
• Maintain both functionalities side-by-side but independently 

To make the problem more complex, assume that we have 500K pages where existing video component is being used today and we don’t want to impact existing pages.

How is the bank going to achieve this? The bank needs to ensure that existing functionality (Google analytic tracking) is not impacted. Let’s look at some of the options first, we’ll discuss solution later.

 As you can see both approaches can impose additional risk and demands time. This translates to additional expense.

Is there better way to handle this? 

Yes, this is where Proxy Component and Component Versioning can help.

What is Proxy Component?

AEM relies on “sling:resourceType” property to identify which component is responsible for rendering. The rendering component can further extend from another parent component using “sling:resourceSuperType” property. This concept is similar to Object Oriented programming (a class can extend from another class). But where is the proxy component? 

Proxy component is a component that is just a placeholder component whose “sling:resourceSuperType” property points to an actual rendering component. Instead of using actual component while creating pages/content, we refer to this proxy component. Think of this proxy component as an interface (in Object Orient programming). Implementation behind interface can change without asking consumers of interface to change anything forcefully. Similar, if we are using proxy component, we can point to a different component in future (by updating the sling:resourceSuperType property of proxy component). We don’t need to update the “sling:resourceType” property in content tree.

This is typically useful when a component is already used and we don’t want to find all the references and replace them one by one. We can simply change the pointer (sling:resourceSuperType property) of proxy component to point to new implementation/version of component. We’ll see versioning next.

What is component versioning?

As name suggests, component versioning allows us to create different version of same component. If we were to compare this with object-oriented programming, think of component versions as various implementation of a base component (or interface or abstract class). Each version of component inherits the functionality from base component and then we can add/update new features. Proxy component allows us to switch the implementation from one version to another. We’ll look at an example later in this article.

We can use above capabilities to address scenarios like what we have one (banking video component scenario that we assumed above in this article). The company could use proxy component and component versioning to reduce the risk.

Let’s talk about an example solution. Let’s see how we can structure our video component using proxy component pattern and leverage component versioning which will allow us to switch from one implementation to another easily.

//The page (cq:Page) in "united-states" site where video component is being used
{
"/content/my-bank/united-states/home/jcr:content/video":'',
"jcr:primaryType":"nt:unstructured",
// Pointing to proxy component (see below)
"sling:resourceType":"my-bank/components/video"
}

// This is PROXY video component pointing to (v1) of video component
{
"/apps/my-bank/components/video":'',
"jcr:primaryType":"cq:Component",
// Pointing to v1 of Video component
"sling:resourceSuperType":"my-bank/core-component-lib/video/v1/video"
}

// v1 Component: GOOGLE Analytics tracking implementation
{
"/apps/my-bank/core-component-lib/video/v1/video":'',
"jcr:primaryType":"cq:Component",
"video.html":"",
// This is based Model interface
"data-sly-use.model":"com.suryakand.demo.model.Video"
}

// Model interface (implemented by both V1 and V2 version of Video component)
package com.suryakand.demo.model;
publicinterface Video {

}

// Model implementation (for version v1) of Video component
package com.suryakand.demo.model.impl.v1;// Note the package name (v1)
@Model(
  adaptables = SlingHttpServletRequest.class,
  adapters ={ Video.class},
// Note the (v1) in resource path
  resourceType ="my-bank/core-component-lib/video/v1/video"
)
publicclass VideoImpl implements Video {

}

// v2 Component: ADOBE Analytics tracking implementation
{
"/apps/my-bank/core-component-lib/video/v2/video":'',
"jcr:primaryType":"cq:Component",
"video.html":"",
// This is based Model interface
"data-sly-use.model":"com.suryakand.demo.model.Video"
}

// Model implementation (for version v2) of Video component
package com.suryakand.demo.model.impl.v2;// Note the package name (v2)
@Model(
  adaptables = SlingHttpServletRequest.class,
  adapters ={ Video.class},
// Note the (v2) in resource path
  resourceType ="my-bank/core-component-lib/video/v2/video"
)
publicclass VideoImpl implements Video {

}