Enabling Single Sign-On 

Allow users to log in with a simple click. 

Single Sign-On (SSO) allows users to log in to OnBoard through a third-party system’s credentials. OnBoard integrates with a few different SSO providers to allow easy access when users sign in via the specified provider. This article will be used to cover the following topics around SSO. 

• What is single sign-on and how does it work? 
• Which SSO protocols and IdPs does OnBoard support? 
• What steps are involved in setup? 
• What does the end user login process look like when SSO is enabled? 
• What does it mean to enforce vs. not enforce SSO? 
• Can I setup SSO for non-organization domain email?  

What is single sign-on and how does it work? 

Single sign-on (SSO) is an authentication method that enables users to securely authenticate with multiple applications and websites by using just one set of credentials. This single set of credentials are stored in an identity provider (IdP for short). An IdP is the 3rd party software that an organization sets up to securely manage the login for various applications that the organization may use all in one place and allow their users to log in to the various applications they may use for the organization with one set of login credentials. 

Applications, such as OnBoard, support single sign-on and different SSO protocols. An SSO protocol, simply put, is the "language" used to communicate between an identity provider and an application. Any IdP that communicates using a protocol supported by that application (in this case OnBoard) will be able to integrate their IdP to that application for SSO support. 

Which SSO protocol does OnBoard support? 

OnBoard supports the SAML SSO protocol.

• SAML – Security Assertion Markup Language 

What SSO Identity Providers (IdP) does OnBoard support? 

OnBoard supports any IdP that communicates using the SAML protocol.

What steps are involved in setup? 

Once you have purchased SSO, you will be ready to get started setting up for your organization. To set up your organization with SSO, you will need to include the following stakeholders: 

• OnBoard Customer Success Manager or Implementation Manager 
• Your organization’s IT manager or someone with access and knowledge on SSO and your organization’s IdP 
• Your organization’s OnBoard administrator 

Below are the steps your organization will take to get started: 

1. Send your IT representative the appropriate information to set up your IdP with a single sign on application for OnBoard. Your OnBoard contact will be able to provide you with this information. 
2. Your IT representative will share the following information with your OnBoard organization administrator including: 
   • For SAML they will share: 
     • The IdP Metadata URL 
3. Your OnBoard Organization Administrator will then log into OnBoard, Click “Settings” tab, and then select “Security” and select the following. 
   1. Enable the SSO toggle.
   2. Click "Set Domain."
   3. Enter your Domain and email address.
   4. You'll need to then check your email for a code to enter then click "Submit."
   5. Click "Configure Provider."
   6. Select the proper Framework and Provider. 
   7. Add the necessary data received from your IT rep. 
   8. Add a display name (e.g., “your organization name SSO”) 
   9. Once you click "Set Configuration" you should be able to log in using SSO!

Your OnBoard CSM or Implementation manager with help you test the SSO to see if it works properly.  

What does the end-user login process look like once it’s set up? 

Web SSO Experience

If signing in on the web browser, the end user will automatically be prompted to sign in with SSO after entering their OnBoard ID (email address). If enforced, their only option will be to sign in with SSO. If not enforced (or if the user is a member of multiple OnBoard organizations) they'll have the option to sign in with their OnBoard ID and password or SSO. 

Please see this article for a more detailed step-by-step login process using SSO. 

Mobile SSO Experience

On the mobile apps, users will be prompted to sign in with SSO automatically if their email address contains the email domain configured in the SSO Settings.

If the end user's email does not contain the configured email domain, they have two options. 

Option 1: Sign in with OnBoard ID and Password First

End users can first sign in with their OnBoard ID and password. Once logged in, they'll access the organization select screen where the Login with SSO button will be available on their organization's tile.

Option 2: Sign in with a Linked Account

This options bypasses the need to sign in with the OnBoard ID and password. From mobile app login screen, end users can select Sign in with a Linked Account. On the next screen, they'll enter their email address and select continue. After entering their email address they'll be prompted to sign in with SSO.

Please see this article for a more detailed step-by-step login process using SSO. 

What does it mean to enforce or not enforce SSO? 

Your organization may choose to enforce or not enforce SSO upon login to OnBoard. If SSO is enforced, the user will have to login to OnBoard using their SSO credentials. If it is not enforced, the user can choose to log in through SSO or through their OnBoard username and password.

If your organization chooses to enforce login, it is recommended that IT includes the users preferred email address in the SSO set up process to ensure they receive all notifications from OnBoard in their inbox. These include calendar invites, reminders, and other important notifications to help board members stay engaged with all board meeting activities and materials.

Need more help? Contact your CSM or Implementation Manager. You can also contact us at help@onboardmeetings.com. Please include “SSO Set up” in the subject line.  

Can I setup SSO for non-organization domain email? 

OnBoard SSO login works by recognizing that a user’s OnBoard email matches an email inside of the identity provider. This means that, if you wish to setup or enforce SSO for those non-organization domain emails, you will need to use that same email in both OnBoard and the IdP. 

If you are not wanting to enforce SSO, users with your organization’s email domain will still be routed through their SSO login to make things easier, but the members with non-organization domain emails will still be able to access via the normal login process. 

FAQs 

1. What is an SSO protocol? 
   • The Protocol is the "language" used to communicate - SSO is done by using a language to communicate between our OB product and the 3rd party identity provider. 
2. What is an identity provider? 
   • The identity provider (or IdP for short) is the 3rd party software that an organization sets up to: 
     • Securely manage the login for various applications that the organization may use all in one place. 
     • Allow their users to log in to the various applications they may use for the organization with 1 set of login credentials. 
3. Does supporting SAML give support for all IdPs? 
   • No, not all IdPs support all protocols, but, if you use one of our supported protocols, we can work quickly to support your IdP. 
4. What is SAML? 
   • Security Assertion Markup Language - This is one of the main protocols (languages) used to communicate between the IdP (identity provider) and the application being logged into (in this case OnBoard). 
5. Does OnBoard auto-provision accounts?
   • No, OnBoard does not auto-provision accounts currently. Users will have to be created in OnBoard with emails that match the email used for that same user created in their identity provider. OnBoard matches those accounts up upon login via email.
6. If I manage multiple organizations, can we use the same email Sign-On Domain for every organization?
   • Yes. Linking the same Sign-On Email Domain for multiple Organizations will provide your users with buttons for every Organization using that Sign-On Domain.
7. How can I verify if my metadata URL is correct?
   • Check if your metadata URL is correct by entering and opening the URL in your web browser. If the URL is valid, you should see XML data displayed. If instead you receive a “Not Found” error or a similar message, the metadata URL is likely incorrect and may need to be updated.