Autenticação e autorização no CXone

Esta página fornece informações específicas sobre como a autenticação e a autorização funcionam em CXone. Se esta for a primeira vez que você trabalha com esses conceitos, primeiro você deve obter um entendimento básico das básico das ideias e terminologia de autenticação e autorização.

Depois de revisar este material, você estará pronto para:

Quando os usuários fazem login em qualquer suíte de aplicativos, incluindo CXone , essas duas etapas geralmente ocorrem na ordem mostrada:

Autenticação — O usuário é quem eles afirmam ser?
Autorização — O usuário autenticado deve ter o acesso que solicitou?

Todos os usuários devem ser autenticados e autorizados antes que possam acessar CXone .

Os usuários podem ser pessoas ou aplicativos. Por exemplo, chatbots e assistentes virtuais geralmente são executados por meio de uma conta de usuário. A maioria dos conjuntos de aplicativos usa os mesmos processos para usuários humanos e virtuais. Nestas páginas de ajuda on-line sobre autenticação e autorização, usamos o termo usuário para aplicar a pessoas e aplicativos. Se houver diferenças, elas são claramente explicadas.

A autenticação pode ser complicada de configurar e difícil de testar e validar. Para configurar a autenticação no CXone, você precisa entender:

Como funciona a autenticação no CXone
O provedor de identidade CXone integrado
Provedores de identidade externos
Diferenças entre autenticar usuários humanos e usuários de aplicativos

Você também precisa saber como funciona a autorização na plataforma CXone.

Esta ilustração mostra como o CXone autentica e autoriza usuários:

Um usuário acessa o CXone através de um navegador da web compatível.
O CXone solicita as credenciais de login do usuário.
O usuário fornece as credenciais.
OCXone verifica com um provedor de identidade (IdP). O CXone tem seu próprio IdP integrado, mas ele também pode funcionar como um IdP externo.
Depois que o usuário é autenticado, o Servidor de autorização do CXone permite o acesso à plataforma CXone. O CXone não é compatível com sistemas externos de autorização.

Autenticação usando o provedor de identidade integrado

O IdP CXone integrado autentica usuários com um nome de usuário e senha. Cada nome de usuário deve ser exclusivo para sua empresa. Opcionalmente, você pode adicionar autenticação multifator (MFA) para obter uma camada de segurança adicional.

Usuários do aplicativo

Às vezes os aplicativos precisam acessar os recursos e funcionalidades do CXone. I CXone trata esses aplicativos, como bots e assistentes virtuais interativos (IVAs), como usuários. Os usuários do aplicativo são suportados apenas com autenticação integrada. Além disso, os usuários do aplicativo não usam autenticadores de login. Em vez disso, eles usam chaves de acesso.

Login de usuário com autenticação integrada

Os usuários primeiro veem uma tela que solicita seu nome de usuário. Se o CXone não souber o nome de usuário, ele não consegue solicitar credenciais adicionais. O CXone só pode solicitar senhas ou tokens MFA quando souber qual usuário está fazendo login.

Depois que o usuário inserir seu nome de usuário e clicar em PRÓXIMO, uma nova janela solicitará a senha do usuário. Assim que o usuário digitar a senha correta e clicar em Entrar, o CXone autentica o usuário e concede acesso ao sistema.

Esta janela parece um pouco diferente para funcionários que foram configurados para usar a MFA. Depois que o usuário inserir seu nome de usuário e clicar em PRÓXIMO, uma nova janela solicitará a senha do usuário e o token da MFA. Depois que o usuário digitar a senha correta e um token válido, ele clicará em Entrar. O CXone autentica o usuário e permite o acesso ao sistema.

Gerenciamento de senhas com autenticação integrada

Os critérios de senha podem ser personalizados com autenticadores de autenticadores de login. Com um autenticador de login, você pode controlar:

Número de caracteres necessários em uma senha
Tipos de caracteres necessários em uma senha
Número de dias antes que o usuário precise redefinir sua senha
Número de tentativas de senha errada permitidas antes que a conta seja bloqueada
Número de senhas que CXone lembra, o que impede que os usuários reutilizem essas senhas

As senhas não são visíveis em CXone . Para privacidade e segurança, as senhas são mantidas internamente e só podem ser alteradas usando um fluxo de senha esquecida ou reenviada. Os usuários podem usar o link na tela de login de senha e seguir as instruções na tela. Os usuários receberão um e-mail notificando que a senha deles foi alterada.

CXone vem com um autenticador de login padrão que você pode usar se não precisar de autenticadores de login personalizados. Você ainda deve atribuir este autenticador padrão ao usuários você quer usá-lo.

Você pode configurar quantos autenticadores de login personalizados desejar. Por exemplo, você pode exigir senhas mais complexas para usuários que tenham acesso a informações valiosas. Sempre que você quiser tornar um requisito de autenticação diferente para uma conta de usuário, precisará criar um novo autenticador de login. As alterações nos autenticadores se aplicam aos usuários atribuídos na próxima vez que eles fizerem login.

Você também pode configurar a autenticação com autenticadores de login personalizados. A MFA aumenta sua segurança adicionando outra camada de autenticação. Por exemplo, você pode fazer com que seus usuários se autentiquem com um nome de usuário e senha. Em seguida, você pode fazer com que eles se autentiquem novamente com um código enviado para seus dispositivos móveis. Esses códigos são normalmente conhecidos como tokens MFA, mesmo quando um token físico não está envolvido.

CXone suporta os dois principais tipos de MFA:

Baseado em tempo — normalmente usado por autenticadores de software como o Google
Baseado em contador — normalmente usado por tokens de hardware

Você pode habilitar a MFA para autenticadores de login com uma única caixa de seleção. No entanto, as informações específicas sobre usuários, suas configurações de MFA e suas identidades são mantidas na conta individual do funcionário.

Os autenticadores de login e os perfis de segurança são completamente separados. Isso significa que o método de autenticação de um funcionário não tem relação com o que ele pode acessar no CXone .

Autenticação usando um provedor de identidade externo

Ao entrar em um sistema com uma conta de outro site, você está usando autenticação externa. Por exemplo, você pode fazer login em um aplicativo em seu telefone com sua conta do Google.

A autenticação externa, às vezes chamada de federação, usa um provedor de identidade externo (IdP) para ajudar a autenticar usuários. O IdP externo trabalha com o CXone IdP para autenticar o usuário. Para trabalhar em conjunto, ambos os IdPs contam com protocolos de autenticação .

IdPs externos

CXone oferece suporte a provedores de identidade de serviços hospedados e em nuvem.

Você deve estar familiarizado com seu provedor de identidade. Caso contrário, trabalhe com a equipe da sua empresa que gerencia a autenticação. Configurar a federação pode ser difícil se as pessoas certas não estiverem envolvidas. Sua organização pode ter estabelecido processos para integrar sistemas como CXone com seu provedor de identidade. Seguir esses processos e atender às suas necessidades específicas de segurança é sua responsabilidade. o NICE CXone equipe está aqui para apoiá-lo ao longo do caminho.

Protocolos de autenticação

Os protocolos de autenticação estabelecem comunicação e confiança entre diferentes IdPs. CXone suporta estes protocolos de autenticação:

OpenID Connect
SAML 2.0

OpenID Connect tem mais recursos e é mais fácil de suportar. Os benefícios incluem:

Tecnologia padrão da indústria
Permite integração IdP perfeita que é transparente para os usuários
Habilita uma variedade de opções de autenticação multifator (MFA)
Base escalável para um modelo de serviço de plataforma

OpenID Connect valida autenticações com assinatura de certificado público/privado usando um padrão do setor chamado JWKS. Portanto, OpenID Connect A configuração determina como os certificados públicos são obtidos. A confiança com o emissor do certificado é estabelecida usando um identificador de cliente e um segredo.

SAML 2.0 é uma tecnologia mais antiga que pode causar problemas de integração. No entanto, atualmente é mais amplamente utilizado do que OpenID Connect . Sua organização pode ter diretrizes sobre qual protocolo deve ser usado. Em geral, ambos oferecem uma experiência de usuário semelhante e um nível subjacente de segurança.

Ambos OpenID Connect e SAML 2.0 fluxo de autenticação iniciado pelo provedor de serviços de suporte (SP). Este é um fluxo familiar e o modelo usado por muitos aplicativos e sites. A experiência do usuário é:

Os usuários inserem suas credenciais em CXone (ou seja, eles fazem login).
CXone usa seu IdP integrado para se comunicar com seu IdP externo para verificar a identidade do usuário.
CXone usa sua autorização integrada para verificar os níveis de acesso do usuário autenticado.
CXone fornece acesso correto ao usuário autenticado e autorizado.

SAML 2.0 também oferece suporte ao fluxo iniciado pelo provedor de identidade (IdP) menos comum. Nesse fluxo, seu usuário insere suas credenciais com seu provedor de identidade. Em seguida, o provedor de identidade inicia CXone .

Para SAML 2.0, o CXone permite apenas assinar a mensagem/resposta, não a declaração.

Fluxos iniciados por IdP se aplicam a aplicativos individuais, e não ao pacote CXone inteiro. Por exemplo, você pode usar esse fluxo para iniciar os principais aplicativos da interface do usuário, mas não pode usá-lo para iniciar outros aplicativos, como o Studio. Para o pacote inteiro funcionar perfeitamente, o fluxo iniciado por SP é necessário.

Seus usuários podem estar familiarizados com um ou ambos os fluxos de autenticação. Se você usar SAML 2.0 , então esteja ciente das limitações apresentadas por cada fluxo. Estes são discutidos mais na próxima seção. OpenID Connect sempre usa o fluxo iniciado por SP.

CXone não suporta criptografia adicional oferecida por alguns protocolos de autenticação.

Os detalhes de configuração diferem com base no IdP e no protocolo de autenticação que você escolher. Não é possível cobrir todas as combinações possíveis de IdPs e protocolos de autenticação, mas alguns cenários comuns são discutidos nas informações a seguir.

Avalie a combinação

o CXone suite não suporta todas as combinações de aplicativo, IdP externo e protocolo de autenticação. Em alguns casos, o suporte não existe. Em outros casos, há limitações com soluções alternativas. É difícil mostrar possíveis problemas para cada combinação e cenário, portanto, você deve fazer uma configuração de teste com seu provedor de identidade. Seu teste deve levar em consideração seus diferentes casos de uso e fluxos de usuários. A tabela a seguir pode ajudar a orientar sua avaliação.

CXoneInscrição	IDP externo	Protocolo de autenticação	Limitações e soluções alternativas
CXone Plataforma e todos os aplicativos	Todos	Todos	Não suporta criptografia de declarações.
CXone Plataforma e todos os aplicativos	Todos	SAML 2.0	Apenas a assinatura de mensagens é suportada. O certificado público deve ser incluído na resposta.
Plataforma CXone	Azure AD	SAML 2.0	Apenas o fluxo iniciado por IdP é suportado.

Somente os aplicativos web principais aceitam o fluxo do SAML 2.0 iniciado por IdP. Os usuários que precisarem acessar o Studio ou os diversos aplicativos de agente deverão usar a autenticação integrada ou um fluxo iniciado por SP.

Estabelecer confiança

Os provedores de identidade devem confiar uns nos outros antes de poderem se comunicar. Cada provedor deve ter informações sobre o outro. Quais informações são necessárias depende do protocolo de autenticação. A forma como as informações são obtidas depende do IdP.

Confiança em OpenID Connect

Seu Representante de Contas do CXone trabalhará com você para configurar um relacionamento confiável entre seu unidade de negócios Alto nível de agrupamento organizacional usado para gerenciar o suporte técnico, cobrança e configurações globais para o seu ambiente CXoneCXone e seu IdP externo usando o OpenID Connect.

Confiança em OpenID Connect envolve estes valores, que você precisará para configurar o relacionamento:

Emissor — Este valor sempre se parece com um URL. Os valores do emissor variam de acordo com seu IdP externo, mas sempre se parecem com um URL. Por exemplo, o Google pode funcionar como um IdP externo e suporta OpenID Connect . O emissor do Google é https://accounts.google.com . Muitos provedores de IdP externos tornam seus URLs de emissor detectáveis anexando ".well-known/openid-configuration" ao final do URL principal do IdP. Isso geralmente fornece informações valiosas adicionais do IdP. A imagem a seguir mostra os tipos de informações fornecidas dessa maneira pelo Facebook em https://www.facebook.com/.well-known/openid-configuration :
Client Identifier — Este valor é atribuído pelo seu IdP externo para você usar com CXone . Durante a autenticação, ele permite que o IdP saiba qual aplicativo está tentando autenticar.
Segredo do cliente — Esse valor garante que a autenticação seja segura e ajuda a garantir que agentes mal-intencionados não possam usar o IdP externo para autenticar em seu unidade de negóciosCXone. CXone suporta apenas client_secret_basic e client_secret_post.

Confiança em SAML 2.0

Existem vários parâmetros de configuração usados para estabelecer confiança com SAML 2.0 . Trabalhe com o seu Representante de Contas do CXone para usar esses parâmetros para criar um relacionamento confiável entre seu unidade de negócios Alto nível de agrupamento organizacional usado para gerenciar o suporte técnico, cobrança e configurações globais para o seu ambiente CXoneCXone e seu IdP externo.

Campo	Detalhes
ID da entidade	Um ID exclusivo global pré-preenchido e não editável que seu IdP externo pode exigir que você insira ao usar o SAML 2.0 protocolo. O IdP o inclui como o ID da entidade do emissor no SAML 2.0 mensagem de solicitação. Alguns IdPs, incluindo Okta e OneLogin, não exigem que você configure o ID da entidade no sistema deles. Outros, incluindo Salesforce, fazem.
URL do terminal	O URL do terminal fornecido pelo seu IdP.
URL de afirmação	Um URL pré-preenchido e não editável que seu IdP precisa para configurar qualquer SAML 2.0 fluxo. Ele serve como um URL de terminal para receber e analisar uma asserção de autenticação. Você deve inserir esse ID na sua configuração de IdP, geralmente no campo URL do ACS. Alguns IdPs chamam isso de algo diferente de ACS. Por exemplo, no modelo Okta SAML 2.0, você insere esse URL no campo URL de logon único.
Certificado	Seu IdP fornecerá um certificado de segurança.

Autenticação de aplicativos

Usuários e aplicativos são autenticados de maneiras muito semelhantes. A principal diferença é que os aplicativos são autenticados com uma chave de acesso enquanto os usuários são autenticados com um nome de usuário e senha. Ao contrário dos usuários, os aplicativos não precisam interagir por meio de um navegador. Eles podem funcionar em um ambiente de back-office.

Você pode criar um perfil de usuário para representar um aplicativo em vez de um usuário. Para fazer isso, crie um perfil de usuário, dê o nome do aplicativo a ele e crie uma chave de acesso. O CXone gerencia a autenticação de aplicativos internamente. Eles não podem ser autenticados com provedores de identidade externos.

Autorização no CXone

A autorização é o processo de verificar quais recursos um usuário tem permissão para acessar. Os recursos podem incluir aplicativos, arquivos e dados. Você pode definir o acesso dos usuários aos recursos com perfis de segurança . O CXone gerencia a autorização automaticamente durante o processo de login. Quando um usuário é autenticado, ele recebe acesso apenas aos recursos para os quais está autorizado.

O método de autenticação de um usuário não afeta a autorização. CXone usa o mesmo processo de autorização para todos os usuários. Não importa se são autenticados com chaves de acesso ou senhas.