Purpose
One of the most effective ways to ensure a secure login for your team and partners is to implement Single Sign On (SSO). Allbound supports SAML and JWT SSO through many different vendors such as Okta, Azure, and Google. The purpose of this article is for Allbound System Admins to be aware of all of the configuration options that are available with SSO so that they may implement the configurations that most align with their business needs.
Available SSO Configuration Options
To access the available SSO configuration options, go to Advanced Settings > SSO Options.
SSO Login
The "SSO Login" functionality solves only one specific use case. If all users, your internal team as well as partners, are to be logging into Allbound through the same Identity Provider (IdP). By activating this and selecting your desired IdP, you will force all users to auto-redirect to your selected IdP upon navigating to the Allbound portal. This will eliminate any possibility of standard email/password login being used.
User Login
The "User Login" settings are the most common configurations used. It allows users to elect which type of authentication they would like to use, SSO or the standard email/password form. Here, you can activate one or several SSO buttons so they may appear on the login page above the login form. This setting is also helpful for use cases where you have multiple IdPs, one for your internal team and another for partners. Checking the setting for "Login only via SSO connections" will hide the standard login form and only show the buttons that you have configured in the field below.
Company-Specific SSO Login
Settings for "Company-Specific SSO Login" allow for a match of the user's email domain to one of the mapped companies on the login page. If the user enters an email address with a matching mapped domain, it will automatically redirect the user to the specific IdP that is mapped to their company. This setting is best utilized if you want to force your internal team to log in via SSO but partner users to still use the standard login form.
Another interesting use case for this feature is if a large partner has an IdP that they are using for their own team(s) that they would like to configure to give their own users an easy way to access the partner portal. You can configure the IdP in the SSO configurations and then map that IdP with these settings, forcing those users to their own IdP to log in.