Authentication and Authorization in CXone

This page provides specific information about how authentication and authorization work in CXone. If this is the first time you've worked with these concepts, you should gain a basic understanding of authentication and authorization ideas and terminology first.

Once you've reviewed this material, you're ready to:

• Set Up CXone Authentication Using the Built-in Identity Provider
• Set Up CXone Authentication Using an External Identity Provider

When users log in to any application suite, including CXone, these two steps typically occur in the order shown:

• Authentication—Is the user who they claim to be?
• Authorization—Should the authenticated user have the access they've requested?

All users must be authenticated and authorized before they can access CXone.

Authentication can be complicated to set up and difficult to test and validate. To set up authentication in CXone, you need to understand:

• How authentication works in CXone

• The built-in CXone identity provider

• External identity providers

• Differences between authenticating human users and application users

You also need to know how authorization works in the CXone platform.

This illustration shows how CXone authenticates and authorizes users:

1. A user accesses CXone through a supported web browser.

2. CXone asks for the user's login credentials.

3. The user provides credentials.

4. CXone verifies them with an identity provider (IdP). CXone has its own built-in IdP, but it can also work with an external IdP.

5. Once the user is authenticated, the CXone Authorization Server provides access to the CXone platform. CXone does not support external authorization systems.

Authentication Using the Built-in Identity Provider

The built-in CXone IdP authenticates users with a username and password. Each username must be unique to your organization. You can optionally add multi-factor authentication (MFA) for an additional security layer.

Application Users

Sometimes applications need access to CXone features and functionality. CXone treats these applications, like bots and interactive virtual assistants (IVAs), as users. Application users are only supported with built-in authentication. In addition, application users don't use login authenticators. Instead, they use access keys.

User Login with Built-in Authentication

Users first see a screen that asks for their username. Until CXone knows the username, it cannot ask for additional credentials. CXone can only ask for passwords or MFA tokens once it knows which user is logging in.

After the user enters their username and clicks NEXT, a new window asks for the user's password. Once the user enters their correct password and clicks Sign In, CXone authenticates the user and grants them access to the system.

This window looks slightly different for users who are configured to use MFA. After the user enters their username and clicks NEXT, a new window asks for the user's password and MFA token. Once the user enters their correct password and a valid token, they click Sign In. CXone authenticates the user and grants them access to the system.

Password Management with Built-in Authentication

Password criteria can be customized with login authenticators. With a login authenticator, you can control:

• Number of characters required in a password

• Types of characters required in a password

• Number of days before the user has to reset their password

• Number of wrong password attempts allowed before the account is locked

• Number of passwords that CXone remembers, which prevents users from reusing those passwords

CXone comes with a default login authenticator you can use if you don't need custom login authenticators. You still must assign this default authenticator to the users you want to use it.

You can set up as many custom login authenticators as you'd like. For example, you can require more complex passwords for users that have access to valuable information. Any time you want to make an authentication requirement different for a user account, you'll need to create a new login authenticator. Changes to authenticators apply to assigned users the next time they log in.

You can also set up multi-factor authentication (MFA) with custom login authenticators. MFA increases your security by adding another layer of authentication. For example, you could have your users authenticate with a username and password. Then, you could have them authenticate again with a code sent to their mobile devices. These codes are typically known as MFA tokens, even when a physical token is not involved.

CXone supports both major types of MFA:

• Time-based—typically used by software authenticators like Google
• Counter-based—typically used by hardware tokens

You can enable MFA for login authenticators with a single checkbox. However, the specific information about users, their MFA settings, and their identities is maintained in the individual employee account.

Login authenticators and security profiles are completely separate. This means an employee's authentication method has no relation to what they can access in CXone.

Authentication Using an External Identity Provider

When you sign in to a system with an account from another site, you're using external authentication. For example, you might log in to an app on your phone with your Google account.

External authentication, sometimes called federation, uses an external identity provider (IdP) to help authenticate users. The external IdP works with the CXone IdP to authenticate the user. To work together, both IdPs rely on authentication protocols.

External IdPs

CXone supports both hosted and cloud service identity providers.

You should be familiar with your identity provider. If not, work with your company team that manages authentication. Setting up federation can be difficult if the right people are not involved. Your organization may have established processes for integrating systems like CXone with your identity provider. Following these processes and meeting your specific security needs is your responsibility. The NICE CXone team is here to support you along the way.

Authentication Protocols

Authentication protocols establish communication and trust between different IdPs. CXone supports these authentication protocols:

• OpenID Connect
• SAML 2.0

OpenID Connect has more features and is easier to support. Benefits include:

• Industry-standard technology

• Allows seamless IdP integration that's transparent to users

• Enables a range of multi-factor authentication (MFA) options

• Scalable foundation for a platform service model

OpenID Connect validates authentications with public/private certificate signing using an industry standard called JWKS. Therefore, OpenID Connect configuration determines how the public certificates are obtained. Trust with the certificate issuer is established using a client identifier and secret.

SAML 2.0 is an older technology that can cause integration problems. However, it is currently more widely used than OpenID Connect. Your organization may have guidelines on which protocol should be used. In general, they both offer a similar user experience and underlying level of security.

Both OpenID Connect and SAML 2.0 support service provider (SP)-initiated authentication flow. This is a familiar flow and the model used by many apps and websites. The user experience is:

• Users enter their credentials in CXone (that is, they log in).
• CXone uses its built-in IdP to communicate with your external IdP to verify the user identity.
• CXone uses its built-in authorization to verify the authenticated user's access levels.
• CXone provides correct access to the authenticated, authorized user.

SAML 2.0 also supports the less-common identity provider (IdP)-initiated flow. In this flow, your user enters their credentials with your identity provider. Then, the identity provider launches CXone.

For SAML 2.0, CXone only supports signing the Message/Response, not the Assertion.

Your users may be familiar with either or both of these authentication flows. If you use SAML 2.0, then be aware of the limitations presented by each flow. These are discussed more in the next section. OpenID Connect always uses the SP-initiated flow.

CXone does not support additional encryption offered by some authentication protocols.

Configuration details differ based on the IdP and authentication protocol you choose. It's not possible to cover all possible combinations of IdPs and authentication protocols, but a few common scenarios are discussed in the information that follows.

Evaluate the Combination

The CXone suite does not support every combination of application, external IdP, and authentication protocol. In some cases, support doesn't exist. In other cases, there are limitations with workarounds. It's difficult to show potential issues for every combination and scenario, so you should do a test setup with your identity provider. Your test should take into account your different use cases and user flows. The following table can help guide your evaluation.

CXone Application	External IDP	Authentication Protocol	Limitations and workarounds
CXone Platform and All Applications	All	All	Does not support encryption of claims.
CXone Platform and All Applications	All	SAML 2.0	Only message signing is supported. Public certificate must be included in the response.
CXone Platform	Azure AD	SAML 2.0	Only IdP-initiated flow is supported.

Establish Trust

Identity providers must trust each other before they can communicate. Each provider must have information about the other. What information is required depends on the authentication protocol. How the information is obtained depends on the IdP.

Trust in OpenID Connect

Your CXone Account Representative will work with you to configure a trusted relationship between your CXone business unit High-level organizational grouping used to manage technical support, billing, and global settings for your CXone environment and your external IdP using OpenID Connect.

Trust in OpenID Connect involves these values, which you'll need in order to configure the relationship:

• Issuer—This value always looks like a URL.Issuer values vary depending on your external IdP, but they always look like a URL. For example, Google can work as an external IdP and it supports OpenID Connect. The Google issuer is https://accounts.google.com. Many external IdP providers make their issuer URLs discoverable by appending ".well-known/openid-configuration" to the end of the primary URL for the IdP. This often provides you with additional valuable information from the IdP. The following image shows the types of information provided in this way by Facebook at https://www.facebook.com/.well-known/openid-configuration:

  

• Client Identifier—This value is assigned by your external IdP for you to use with CXone. During authentication, it lets the IdP know what application is trying to authenticate.
• Client Secret—This value ensures the authentication is secure and helps ensure malicious actors cannot use the external IdP to authenticate into your CXone business unit. CXone supports only client_secret_basic and client_secret_post.

Trust in SAML 2.0

There are several configuration parameters used to establish trust with SAML 2.0. Work with your CXone Account Representative to use these parameters to create a trusted relationship between your CXone business unit High-level organizational grouping used to manage technical support, billing, and global settings for your CXone environment and your external IdP.

Field	Details
Entity ID	A pre-populated, non-editable global unique ID that your external IdP may require you to enter on their side when using the SAML 2.0 protocol. The IdP includes it as the entity ID of the issuer in the SAML 2.0 request message. Some IdPs, including Okta and OneLogin, don't require you to configure the entity ID on their side. Others, including Salesforce, do.
Endpoint URL	The endpoint URL provided by your IdP.
Assertion URL	A pre-populated, non-editable URL your IdP requires to set up any SAML 2.0 flow. It serves as an endpoint URL for receiving and parsing an authentication assertion. You must enter this ID in your IdP configuration, usually in the ACS URL field. Some IdPs call it something other than ACS. For example, in the Okta SAML 2.0 template, you enter this URL in the Single Sign On URL field.
Certificate	Your IdP will provide you with a security certificate.

Authentication of Applications

Users and applications are authenticated in very similar ways. The main difference is that applications are authenticated with an access key while users are authenticated with a username and password. Unlike users, applications are not required to interact through a browser. They can function in a back-office environment.

You can create a user profile to represent an application instead of a user. To do so, create a user profile, name the profile after the application, and create an access key. CXone manages the authentication of applications internally. They cannot be authenticated with external identity providers.

Authorization in CXone

Authorization is the process of verifying what resources a user is allowed to access. Resources can include applications, files, and data. You can define users' access to resources with security profiles. CXone manages authorization automatically during the login process. When a user is authenticated they are given access only to the resources they're authorized for.

A user's authentication method doesn't impact authorization. CXone uses the same authorization process for all users. It doesn't matter whether they are authenticated with access keys or passwords.