Jibility introduced enterprise security for our Enterprise plans in 2021. The Jibility enterprise security feature addresses security concerns related to

1) Customer Identity management - Single Sign-on;

Single Sign-on (SSO) will enable your users to access Jibility without the need for a Jibility specific username and password. With SSO, Jibility will authenticate a user using your SAML-enabled ID provider, such as Gsuite, Active Directory, Okta, OneLogin and so on.

With SSO, you control the policies and processes that manage your user's authentication requirements, such as username structure, password strength, password expiry and multi-factor authentication.

2) Data isolation - Customer specific data space and domain name; and

A dedicated environment with separated data storage space is created for each customer. Access to Jibility is via a customer specific URL. For example, the RedYabber company may have a URL such as redyabber.jibility.com instead of the generic app.jibility.com.
​

3) Data Sovereignty - Customer's chosen data hosting region.

The customer can nominate which Amazon Web Service (AWS) region hosts their Jibility application and data.

Note, all SSO enabled customers will have a customer specific environment. However, a customer with a customer specific environment may not choose to enable SSO.

This article is focussed on the SSO component of the enterprise security feature.

Without SSO, users must log in to Jibility using a username and password. For example, when a user points their browser to http://app.jibility.com, they will be prompted to enter a username and password to log in.

With SSO configured, the user is authenticated via the customer's identity provider platform. For example, if the company RedYabber utilized Office365 and Microsoft Azure Active Directory for SSO. When the user points their browser to "redyabber.jibility.com", then Jibility will automatically authenticate the user using the customer's Office365 login. If the user has not logged into Office365 then Jibility will redirect the user to Office365 for authentication first.

At the moment, configuring SSO between the customer and Jibility is not automated and will require information exchange and set up between the customer's SAML Administrator and a Jibility staff.

The high-level steps are

1) Customer to provide the contact details of their SAML Administrator.

2) Jibility to contact the customer's SAML administrator with instructions and information required for SSO set up.

3) Jibility will configure the customer's SSO environment in Jibility and provide the basic SAML configuration information to the customer.

4) Customer's SAML Administrator to configure Jibility app in their identity provider platform and forward a copy of the Metadata file to Jibility.

5) Jibility update its SSO configuration based on the customer's metadata file.

6) Jibility to notify the customer when SSO is ready for testing.

7) Customer's SAML administrator to test the SSO setup and confirm.

The following is a detailed explanation of each step

Jibility requires the contact details of the customer's identity provider administrator. This is the person who has the permission and skills required to configure SAML on the customer's identity provider platform.

There are many identity provider platforms in use by different customers. Some common ones are Gsuite, Microsoft Active Directory, Okta and Onelogin.

Jibility will contact the customer's SAML administrator to ensure that there is a common understanding of the objective, timeframe, expectations, availability and technology for setting up SSO.

Jibility will commence setting up a new customer environment and enable this for SSO. The basic SAML configuration information such as the following are forwarded to the customer's SAML administrator to create Jibility as an app in their identity provider software.

In the customer's identity provider platform, the administrator must set up Jibility as a SAML based sign-on app. The basic SAML configuration provided in the previous step is used to configure the app's URL.

When creating Jibility as a SAML based sign-on app, you can download a copy of the Metadata file. Please forward this file to the Jibility staff working with you to configure SSO.

Jibility will extract the required information from the Metadata file to set up the customers SSO config in Jibility. Note, if the Jibility app configuration is changed in the customer's identity provider platform, then it may be necessary to download and forward an updated copy of the Metadata file again.

In addition to setting up the basic SAML configuration, the customer's SAML administrator must also set up the user attributes. Jibility requires two user attributes: name and email. Configuring these two attributes will enable this information to be routed to Jibility to provision a new user and identify the user.

Note, each customer may have a different representation of name and email. The following table shows some example mappings.

To configure Google Gsuite please refer to article Configuring SSO with Google Gsuite and to configure Microsoft ADFS please refer to article Configuring SSO with Microsoft ADFS.

Jibility will upload the customer's metadata file to update SSO configuration with the required endpoint and attribute information.

The customer is informed that SSO is ready for testing. The customer can test Jibility using the customer's domain-specific URL. For example, for RedYabber their URL is https://redyabber.jibility.com.

The customer to test and confirm with Jibility that SSO is working.

Configuring SSO for Google Gsuite

Configuring SSO for Microsoft Active Directory Federated Services (ADFS)