Unified Login (Single Sign-On)

Watch our Unified Login video tutorial here:

Context

At MENU, we have many different domains used to service different functionalities and products within our Ecosystem. This means every time you switch between them, you have to perform login actions in each.

This, along with the migration from CMS to Management Center (MC) made us think what we always think: make it easier, make it simple.

To deliver on that motto to you, we built a Unified Login for all Users. It's our version of Single Sign-On or SSO, which we're sure you've seen before. This means you can now visit a single point and gain access to all trusted domains.

Please note: at the moment, this applies only to CMS and MC. You will have the option to be directed to other MENU applications, but for those, you will still need to log in until they are included in SSO.

Single Sign-On (SSO) - what is it?

SSO is a common integration solution used across the globe by many companies, regardless of their type and size. An SSO system provides unified login authentication for application systems. Users can log in once and gain access to all application systems that trust each other.

Why is it good for me?

SSO improves User experience and reduces security risks and management costs. You save time because you're only logging in once through the 'main gate', and that gate understands that selected applications and websites are safe, so it simply lets you into all the other ones that it trusts!

This is how this trusted applications list will look like (top-right corner of the MC). At MENU, we call this Application Tray or App Tray.

To know more, check this article.

Please note: like we mentioned, Unified Login currently works for MC and CMS. You can access CC, MW and KB from this Admin Panel in MC, however as of now, you'd need to log in until they are included in SSO.

Also, you don't have to worry about the security. Not only is that a 'closed loop' of trust between that main gate and other tools - it's also just one loop, not a multitude of credentials and passwords to remember! 

Security

We have to get technical for a second here. The SSO system is made of the SSO Server and SSO Clients. The SSO Server and SSO Clients authenticate login requests together. The SSO Server generates and manages Certificates. The SSO Clients are deployed with application systems to provide Certificate Authentication Interfaces for the application systems to communicate with the SSO Server.

Step by step authentication flow

So let's talk in easier terms now. Here's how it actually happens, and below you can find a diagram that depicts it:

1. A User goes to the application they want to access: the CMS. CMS is, in this case, the Service Provider
   
   

2. The Service Provider (CMS) sends a Token that contains some information about the User (their email address and application_key header for that User) to the SSO system: the Identity Provider or Authentication Service. In this case, it's the Management Center (MC). So: CMS asks MC - hey, please authenticate this User for me, so I know I can grant them access

   • The Identity Provider (MC) first checks to see whether the User has already been authenticated:
     If yes, then it will grant the User access to the Service Provider (CMS)
     Please note: if the user has already been authenticated, this is called a Global Session. Then the Server sends Authentication Token to ”domain1” and the session cookies are stored in the browser cookie storage. In this case, the next step in step 5.

   • If the User hasn’t logged in (so not authenticated yet), they will be prompted to do so by providing the credentials required by the Identity Provider (MC). In MENU’s case this is simply the email address to generate the passwordless magic link. In this case, the next step is step 3.
     
     

3. The Identity Provider (MC) checks the credentials by sending the email address and application_key header of a User. The Authentication Service will send a signed token back to the Service Provider (CMS), confirming that this User has been identified correctly and they may have the access
   
   

4. The User is redirected to the original domain (CMS). The Token is passed through the User's browser to the Service Provider (CMS). In our case we will return a signed JWT (JSON Web Token) with User's profile information if validation was successful
   
   

5. The Token that is received by the Service Provider (CMS) is validated according to the trust relationship that was set up between the Service Provider (CMS) and the Identity Provider (MC) during the initial configuration. Then creates local session based on JSON Web Tokens payload. CMS cookie is also stored in the browser
   
   

6. The User is gets the access to the Service Provider (CMS)
   
   

7. When the User tries to access a different Service Provider than the CMS, then it is treated as a new Service Provider. It means that it has to have a similar trust relationship configured with the SSO solution. If it does, the authentication flow will follow the same steps