SSO for Ooma

Description: The purpose of this article is to provide an overview of Single Sign-On (SSO) and introduce the key terms and concepts related to implementing SSO for logging into the Ooma Enterprise system.

Single Sign-On (SSO) is an authentication mechanism that enables users to log in to multiple systems or applications using a single set of login credentials. With SSO, once a user has successfully logged in to one application or system, they are automatically authenticated to other applications or systems within the same SSO environment. This simplifies the login process for users, eliminates the need for multiple sets of credentials, and enhances security. 

SSO is widely employed in enterprise environments to provide secure and streamlined access to a variety of mission-critical applications and services.

Any SSO interaction involves three participants:

• User: a common end user.
• Service Provider (SP): a web resource the user tries to get access to, which is responsible for providing a requisite service to the end user. 
• Identity Provider (IdP): a third-side centralized system that stores and manages the user credentials and other identifying information.

Throughout this article series, we will designate Ooma Enterprise as the only SP for each of the described cases of SSO integration. The SP will be integrated with various IdPs, including Azure, Okta, Google, and Auth0.

To establish intrasystem interactions, SPs and IdPs should use one of the standards for identity data transferring. In Ooma Enterprise, we use SAML as an interaction language for this purpose.

SAML (Security Assertion Markup Language) is an XML-based open standard for transferring identity data between IdP and SP. 

SAML allows SPs to avoid conducting authentication themselves and instead receive identity information to integrate internal and external users. It facilitates the sharing of security credentials between the SP and other applications or services over a network. By supporting the SAML protocol, you can enable SSO between two applications, granting SSO the ability to handle multiple security tasks for one or more applications.

A diagram illustrating the login process of a User into a system (SP) that uses SSO appears as follows:

In order to establish data transfers, configurations are required on both the SP and IdP sides. Below, you will find a list of links categorized by IdPs, which will direct you to the corresponding configuration guides for both the IdP and the SP.

Here you can find the definitions of the key terms and concepts associated with the implementation of SSO:

• Glossary

Overview of the Admin Portal interface for SSO

• How to configure Ooma Enterprise as an SP.

Azure Active Directory

• Microsoft Azure Registration.
• How to Create and Configure an Azure AD DS managed domain.
• How to add Ooma (SP) to Azure AD.
• Configuring the Ooma / Azure AD SSO Integration.

Okta

• Configuring the Ooma / Okta SSO Integration. 

Auth0

• Configuring the Ooma / Auth0 SSO Integration. 

Google

• Configuring the Ooma / Google SSO Integration. 

Microsoft 365

• How to create a user in Microsoft 365.
• Microsoft Azure Registration.
• How to Create and Configure an Azure AD DS managed domain.
• How to add Ooma (SP) to Azure AD.
• Configuring the Ooma / Microsoft 365 SSO Integration.

To gain further insights into the end-user's experience with SSO, read this article.

• The Ooma Enterprise Desktop App. SSO.