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 employees 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. If you have configured a login requirement based on location, CXone checks the user's IP address to make sure it matches the allowed IP addresses. 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 roles 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 are assigned to roles. This means an employee's authentication method depends on the role they are assigned.

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 an authentication protocol called SAML 2.0.

SAML 2.0 is an established technology and is widely used than newer technologies like OpenID Connect. It supports 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 a less-common IdP-initiated flow. In this flow, your user enters their credentials with your IdP. Then, the IdP 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, be aware of the limitations presented by each flow. These are discussed more in the next section.

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

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	All	OpenID Connect	Not 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.

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 tenant 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 an employee profile to represent an application instead of a user. To do so, create an employee 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 roles. 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.