Auto Log-on for Single Sign-On

Owned by Ravikumar Babu CTOO (Unlicensed)
Last updated: Nov 08, 2018

The Auto Log-on feature of Canvas allows organizations to merge apps built by different vendors into a single mobile application.

The implementation teams can embed mobile apps built with the latest Canvas Technology into apps built with older versions of Canvas Technology or other frameworks. This is achieved by availing the services of a single sign-on (SSO) provider for both the Parent and Child apps. Once logged in from the Parent App, the Child App continues to operate without prompting for a log-on and vice versa.

Architectural Flow

The following image shows the architectural flow of the Auto-Log-on feature followed by scenario-based explanation.


Scenario 1: The user logs on to the Parent App and accesses the Child App

  1. When the user logs on to the Parent App with the credentials, the Parent App server validates the user via the SSO provider.
  2. The SSO provider checks if the user exists in its server. If the user is present in its server, it sends a success response to the Parent App server along with the armor cookie (the example provided in this document refers to the armor cookie as the armorTicket).
  3. The Parent App server performs the entitlement check. If the validation is successful, it provides access to the Parent App and also sets the armor cookie in the HttpServletResponse object. Being logged in to the Parent App, the user can continue to use the Parent App server.
  4. Now when the user chooses to access the Child App, the cookie set for the Parent App server is retrieved by the Parent App using the CookieMaster Plugin and is set for the Child App server using the same plugin. Now when the Child App is launched, every request will contain the armor cookie which is sent by the Child App server to the SSO provider. The SSO provider checks to whom the armor cookie is assigned and sends a success response along with the log-on ID to the Child App server. The Child App server performs the entitlement check. If the validation is successful, it provides access to the Child App.

The same process applies if there is a session timeout in the Parent App.

Scenario 2: The user logs out of the Child App or there is a session time out in the Child App

  1. On logging out of the Child App, the log-on page of the Child App displays. When the user logs on to the Child App with the credentials, the Child App server validates the user via the SSO provider.
  2. The SSO provider checks if the user exists in its server. If the user is present in its server, it sends a success response to the Child App server along with the armor cookie (the example provided in this document refers to the armor cookie as the armorTicket).
  3. The Child App server performs the entitlement check. If the validation is successful, it provides access to the Child App and also sets the armor cookie in the HttpServletResponse object. Being logged in to the Child App, the user can continue to use the Child App server.
  4. Now when the user chooses to access the Parent App, the cookie set for the Child App server is retrieved by the Child App using the CookieMaster Plugin and is set for the Parent App server using the same plugin. Now when the Parent App is launched, every request will contain the armor cookie which is sent by the Parent App server to the SSO provider. The SSO provider checks to whom the armor cookie is assigned and sends a success response along with the log-on ID to the Parent App server. The Parent App server performs the entitlement check. If the validation is successful, it provides access to the Parent App.

Refer the following links, for more information:

Refer the following pages: