In many enterprise organizations, it is common to use a Single Sign-On (SSO) provider (such as Okta or Google) to manage application access from one central facility. In order to support this, MessageGears has built Accelerator to comply with a common standard for implementing SSO, SAML 2.0. This document explains the basics of how SSO works with MessageGears software and how to set up an instance of Accelerator to use SSO.
Before we get into the details of SSO, let's first cover how MessageGears handles authentication without SSO. MessageGears has two primary components of software:
- Accelerator is the on-premise software that is installed behind your firewall or in your private cloud next to your marketing database.
- There is also a MessageGears' Cloud component which is where we render and send your messages to the various ISPs.
In a typical authentication scenario, all users (and their roles) are stored in the MessageGears cloud. So, when you log into Accelerator, it checks Cloud to see if the username is valid and what roles that user has.
When you enable SSO for your instance of Accelerator, Accelerator will instead call your Identity Provider (IdP) to determine if the user is a valid user. Accelerator itself will store the roles of the various users, so part of the set-up of SSO will be to create users that are local to Accelerator. It is recommended that you create all new local users after enabling SSO (rather than trying to migrate any of the users in Cloud to the local Accelerator instance). Please contact Client Success for more details.
Once the Accelerator administrative setup is complete and the local Accelerator users have been properly created, the login flow will look like this (using Okta as the example IdP).
In the case where SAML is having issues, there will continue to be a separate URL where you can login to Accelerator (using Cloud to authenticate the user) that we'll cover at the end of this document.
Using Single Sign On
Once the SAML has been setup, users will access Accelerator using the typical URL and they will follow the flow outlined below.
- The user tries to access a page within an instance of Accelerator.
- Accelerator sends a redirect message back to the user’s browser and includes the URL that the user was trying to access.
- The user’s browser forwards the redirect on to Okta / Google.
- If the user doesn’t have a valid session, the corresponding login page is displayed.
- Once the user logs in, Okta / Google generates the SAML Assertion for that particular user.
- When the SAML Assertion reaches Accelerator, Accelerator looks to see if the Username is valid and unlocked. The user is logged in at that point.
- Finally, Accelerator determines whether the user has access to the resource defined by the URL and if so, serves the page.
Accessing Accelerator via a Backdoor
In order to facilitate access to Accelerator if there are problems with configuration or communication with the IdP, there is an additional URL that can be used to access Accelerator using a Cloud user.
NOTE: It is important that you keep changes to audiences/templates/campaigns/etc. to a minimum. This feature is designed to make Administrative changes and halt campaigns in emergency situations. This access should not be used for regular functionality (as it will not be associated with a local user).