Configurar o provedor de identidade do Cisco Identity Service para ativar o SSO

Introduction

Este documento descreve a configuração no provedor de identidade (IdP) para habilitar o SSO (Single Sign On, logon único).

Modelos de implantação de IdS da Cisco

Produto	Implantação
UCCX	Co-residente
PCCE	Co-residente com CUIC (Cisco Unified Intelligence Center) e LD (Live Data)
UCCE	Coresidente com CUIC e LD para implantações de 2k. Autônomo para implantações de 4k e 12k.

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Cisco Unified Contact Center Express (UCCX) versão 11.5 ou Cisco Unified Contact Center Enterprise versão 11.5 ou Packaged Contact Center Enterprise (PCCE) versão 11.5, conforme aplicável.
• Microsoft Ative Diretory - AD instalado no Windows Server
• Ative Diretory Federation Service (ADFS) versão 2.0/3.0

Note: Este documento faz referência ao UCCX nas capturas de tela e nos exemplos, mas a configuração é semelhante em relação ao Cisco Identify Service (UCCX/UCCE/PCCE) e ao IdP.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Informações de Apoio

Visão geral do SSO

A Cisco fornece vários serviços de diferentes formas e, como usuário final, você deseja entrar apenas uma vez para ter acesso a todos os serviços da Cisco. Se você quiser localizar e gerenciar contatos de qualquer aplicativo e dispositivo da Cisco, utilizando todas as fontes possíveis (Corporate Diretory, Outlook, contatos móveis, Facebook, LinkedIn, Histórico) e fazendo com que eles sejam renderizados de forma comum e consistente, o que fornece as informações necessárias para saber sua disponibilidade e a melhor forma de contatá-los.

SSO usando SAML (Security Assertion Markup Language) é direcionado a este requisito. O SAML/SSO permite que os usuários façam login em vários dispositivos e serviços por meio de uma conta comum e uma identidade de autorização chamada IdP. A funcionalidade SSO está disponível no UCCX/UCCE/PCCE 11.5 em diante.

Visão geral sobre a configuração 

Configurar

Tipos de autenticação

O Cisco Identity Service oferece suporte apenas à autenticação baseada em formulário do Identity Provider.

Consulte estes artigos do MSDN para saber como ativar a autenticação de formulário no ADFS.

• Para o ADFS 2.0, consulte este artigo do Microsoft TechNet,
  http://social.technet.microsoft.com/wiki/contents/articles/1600.ad-fs-2-0-how-to-change-the-local-authentication-type.aspx
  
• Para o ADFS 3.0 consulte este artigo da Microsoft TechNet,
  https://blogs.msdn.microsoft.com/josrod/2014/10/15/enabled-forms-based-authentication-in-AD FS-3-0/

Note: O Cisco Identity Service 11.6 e superior suporta autenticação baseada em formulário e autenticação Kerberos. Para que a autenticação Kerberos funcione, você deve desativar a autenticação baseada em formulário.

Estabelecer relação de confiança 

Para integração e habilitação de aplicativos para usar o Cisco Identity Service para login único, faça a troca de metadados entre o Identity Service (IdS) e o IdP.

• Baixe o arquivo de metadados SAML SP sp.xml.
• Em Configurações, navegue até a guia Confiança de IdS na página Gerenciamento do Serviço de Identidade.

• Baixe o arquivo de metadados IdP do IdP do URL:
  https://<ADFSServer>/federationmetadata/2007-06/federationmetadata.xml

• Na página Gerenciamento de serviços de identidade, carregue o arquivo de metadados do provedor de identidade que foi baixado na etapa anterior.

Este é o procedimento para carregar os metadados de IdS e adicionar regras de solicitação. Isso é descrito para ADFS 2.0 e 3.0

ADFS 2.0:

Etapa 1. No servidor ADFS, navegue para Iniciar > Todos os programas > Ferramentas administrativas > Gerenciamento do AD FS 2.0, como mostrado na imagem:

Etapa 2. Navegue até Add AD FS 2.0 > Trust Relationship > Confiança de terceira parte confiável, como mostrado na imagem:

Etapa 3. Como mostrado na imagem, selecione a opção Importar dados sobre a terceira parte confiável de um arquivo.

Etapa 4. Concluir o estabelecimento da confiança da terceira parte confiável.

Etapa 5. Nas propriedades da Confiança da terceira parte confiável, selecione a guia Identificador.

Etapa 6. Defina o identificador como o nome de host totalmente qualificado do Cisco Identity Server do qual sp.xml é baixado.

Passo 7. Clique com o botão direito do mouse na Confiança da terceira parte confiável e clique em Editar regras de reivindicação.

Você precisa adicionar duas regras de reivindicação, uma é quando os atributos LDAP (Lightweight Diretory Access Protocol) são correspondidos enquanto a segunda é através de regras de reivindicação personalizadas.

uid - Este atributo é necessário para que os aplicativos identifiquem o usuário autenticado.
user_main - Este atributo é necessário para o Cisco Identity Service identificar o território do usuário autenticado.

Reivindicação Rregra 1:

Adicione uma regra pelo nome NameID do tipo (Envie os valores do atributo LDAP como afirmações):

• Selecione Repositório de atributos como Ative Diretory.
• Mapeie o atributo Ldap User-Principal-Name para user_main (em minúsculas).
• Escolha o atributo LDAP que deve ser usado como userId para que os usuários do aplicativo façam logon e o mapeiem para uid (minúsculo)

Exemplo de configuração quando SamAccountName deve ser usado como ID de usuário:

• Mapeie o atributo LDAP SamAccountName para uid.
• Mapeie o atributo LDAP User-Principal-Name para user_main.

Exemplo de configuração quando o UPN precisa ser usado como ID de usuário -

• Mapeie o atributo LDAP User-Principal-Name para uid.
• Mapeie o atributo LDAP User-Principal-Name para user_main.
               

Exemplo de configuração quando PhoneNumber tem que ser usado como ID de usuário -

• Mapeie o atributo LDAP phoneNumber para uid.
• Mapeie o atributo LDAP User-Principal-Name para user_main.

Note: Precisamos garantir que o atributo LDAP configurado para ID de usuário na sincronização LDAP do CUCM deve corresponder ao que está configurado como Atributo LDAP para uid no ID de nome da regra de declaração do ADFS. Isso é para o funcionamento adequado do Cisco Unified Intelligence Center (CUIC) e o login do Finesse.

Note: Este documento faz referência a restrições no nome da regra de declaração e nos nomes de exibição, como NomeID, FQDN do UCCX etc. Embora os campos e nomes personalizados possam ser aplicáveis em várias seções, os nomes das regras de declaração e os nomes de exibição são mantidos como padrão para manter a consistência e para as melhores práticas na convenção de nomenclatura.

Clay Rule 2:

• Adicione outra regra do tipo regra de declaração personalizada com o nome FQDN (Fully Qualified Hostname, nome de host totalmente qualificado) do Cisco Identity Server e adicione este texto de regra.
                                

  c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:2.0:nameid-format:transient", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/namequalifier"] = "http://<ADFS Server FQDN>/ADFS/services/trust", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "<fully qualified hostname of IdS/UCCX>");

  
  
• No cluster do Cisco Identity Server, todos os nomes de host totalmente qualificados são os do nó principal ou do editor do Cisco Identity Server.
  
  
• O <nome de host totalmente qualificado do Cisco Identity Server> diferencia maiúsculas de minúsculas, portanto, corresponde exatamente (incluindo maiúsculas de minúsculas) ao Cisco Identity Server FQDN.
  
  
• O <FQDN do Servidor ADFS> diferencia maiúsculas de minúsculas, portanto, corresponde exatamente (incluindo maiúsculas de minúsculas) ao FQDN do ADFS.

Etapa 8. Clique com o botão direito do mouse na Confiança da terceira parte confiável e, em seguida, clique em Propriedades e selecione a guia avançada, conforme mostrado na imagem.

Etapa 9. Como mostrado na imagem, selecione Secure Hash Algorithm (SHA) como SHA-256.

Etapa 10. Click OK.

ADFS 3.0:

Etapa 1. No servidor ADFS, navegue para Server Manager > Tools > AD FS Management.

Etapa 2. Navegue para AD FS > Relação de confiança > Confiança de terceira parte confiável.

Etapa 3. Selecione a opção Importar dados sobre a entidade confiadora de um arquivo.

Etapa 4. Concluir o estabelecimento da confiança da terceira parte confiável.

Etapa 5. Nas propriedades da Confiança da terceira parte confiável, selecione a guia Identificador.

Etapa 6. Defina o identificador como o nome de host totalmente qualificado do Cisco Identity Server do qual sp.xml é baixado.

Passo 7. Clique com o botão direito do mouse na Confiança da terceira parte confiável e clique em Editar regras de reivindicação.

Você precisa adicionar duas regras de reivindicação, uma é quando os atributos LDAP (Lightweight Diretory Access Protocol) são correspondidos enquanto a segunda é através de regras de reivindicação personalizadas.

uid - Este atributo é necessário para que os aplicativos identifiquem o usuário autenticado.
user_main - Este atributo é necessário para o Cisco Identity Service identificar o território do usuário autenticado.

Reivindicação Rregra 1:

Adicione uma regra pelo nome NameID do tipo (Envie os valores do atributo LDAP como afirmações):

• Selecione Repositório de atributos como Ative Diretory.
• Mapeie o atributo Ldap User-Principal-Name para user_main (em minúsculas).
• Escolha o atributo LDAP que deve ser usado como userId para que os usuários do aplicativo façam logon e o mapeiem para uid (minúsculo)

Exemplo de configuração quando SamAccountName deve ser usado como ID de usuário:

• Mapeie o atributo LDAP SamAccountName para uid.
• Mapeie o atributo LDAP User-Principal-Name para user_main.

Exemplo de configuração quando o UPN precisa ser usado como ID de usuário -

• Mapeie o atributo LDAP User-Principal-Name para uid.
• Mapeie o atributo LDAP User-Principal-Name para user_main.
               

Exemplo de configuração quando PhoneNumber tem que ser usado como ID de usuário -

• Mapeie o atributo LDAP phoneNumber para uid.
• Mapeie o atributo LDAP User-Principal-Name para user_main.

Note: Precisamos garantir que o atributo LDAP configurado para ID de usuário na sincronização LDAP do CUCM deve corresponder ao que está configurado como Atributo LDAP para uid no ID de nome da regra de declaração do ADFS. Isso é para o funcionamento adequado do Cisco Unified Intelligence Center (CUIC) e o login do Finesse.

Note: Este documento faz referência a restrições no nome da regra de declaração e nos nomes de exibição, como NomeID, FQDN do UCCX etc. Embora os campos e nomes personalizados possam ser aplicáveis em várias seções, os nomes das regras de declaração e os nomes de exibição são mantidos como padrão para manter a consistência e para as melhores práticas na convenção de nomenclatura.

Clay Rule 2:

• Adicione outra regra do tipo regra de declaração personalizada com o nome FQDN (Fully Qualified Hostname, nome de host totalmente qualificado) do Cisco Identity Server e adicione este texto de regra.
                                

  c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:2.0:nameid-format:transient", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/namequalifier"] = "http://<ADFS Server FQDN>/ADFS/services/trust", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "<fully qualified hostname of IdS/UCCX>");

  
  
• No cluster do Cisco Identity Server, todos os nomes de host totalmente qualificados são os do nó principal ou do editor do Cisco Identity Server.
  
  
• O <nome de host totalmente qualificado do Cisco Identity Server> diferencia maiúsculas de minúsculas, portanto, corresponde exatamente (incluindo maiúsculas de minúsculas) ao Cisco Identity Server FQDN.
  
  
• O <FQDN do Servidor ADFS> diferencia maiúsculas de minúsculas, portanto, corresponde exatamente (incluindo maiúsculas de minúsculas) ao FQDN do ADFS.

Etapa 8. Clique com o botão direito do mouse na Confiança da terceira parte confiável e, em seguida, clique em Propriedades e selecione a guia avançada

Etapa 9. Como mostrado na imagem, selecione Secure Hash Algorithm (SHA) como SHA-256.

Etapa 10 - Clique em OK.

Essas etapas são obrigatórias após a Etapa 10.

Habilitar Asserções SAML Assinadas para a Confiança da Parte Confiante (Cisco Identity Service)

Etapa 1. Clique em Iniciar e digite powershell para abrir o windows powershell.

Etapa 2. Adicione ADFS CmdLet ao powershell executando o comando Add-PSSnapin Microsoft.Adfs.Powershell.

Etapa 3 - Executar o comando Set-ADFSRelyingPartyTrust -TargetName <Confiança da terceira parte confiável>

-SamlResponseSignature "MessageAndAssertion".

          

Note: A etapa 2 pode não ser necessária se você estiver usando o ADFS 3.0, pois o CmdLet já está instalado como parte da adição das funções e dos recursos.

Note: O <Identificador de Fidedignidade de Confiança de Confiança> diferencia maiúsculas de minúsculas, portanto, corresponde (incluindo caso) ao que está definido na guia Identificador das propriedades de confiança da terceira parte confiável.

Note: Iniciar o UCCX versão 12.0 O Cisco Identity Service oferece suporte a SHA-256. A confiança da terceira parte confiável usa SHA-256 para assinar a solicitação SAML e espera que o ADFS faça o mesmo na resposta.

Para uma configuração de vários domínios para ADFS federado

No caso da Federação no ADFS, em que um ADFS em um domínio específico fornece autenticação SAML federada para usuários em outros domínios configurados, essas são as configurações adicionais necessárias.

Para estas seções, o termo ADFS primário refere-se ao ADFS que tem de ser utilizado em IdS. O termo ADFS Federado indica os ADFS, cujos usuários têm permissão para fazer login via IdS e, portanto, é o ADFS principal.

Configuração do ADFS Federado

Em cada um dos ADFS federados, a fidedignidade da entidade confiadora tem de ser criada para o ADFS primário e as regras de afirmação configuradas como mencionado na seção anterior.

Configuração principal do ADFS

Para o ADFS principal, além da confiança da terceira parte confiável para IdS, a seguinte configuração adicional é necessária.

Adicione a Confiança do Provedor de Afirmações com o ADFS ao qual a federação precisa ser configurada.

Na Confiança do Provedor de Afirmações, certifique-se de que as regras Passar ou Filtrar uma Afirmação de Entrada estejam configuradas com a opção de passar todos os valores de reivindicação

• ID do nome
• Escolha a ID do nome na caixa suspensa Tipo de solicitação de entrada
• Escolha Transient como a opção para o formato Incoming NameID
• uid: Esta é uma reivindicação personalizada. Insira o ID do valor na caixa suspensa Tipo de solicitação de entrada.
• user_principal: Esta é uma reivindicação personalizada. Digite o valor user_main na caixa suspensa Incoming Claim Type.

Na confiança da terceira parte confiável para IdS, adicione as regras Passar por ou Filtrar uma reivindicação de entrada com a opção passar por todos os valores da reivindicação.

• NomeIDFromSubdomínio
• Escolha a ID do nome na caixa suspensa Tipo de solicitação de entrada
• Escolha Transient como a opção para o formato Incoming NameID
• uid: Esta é uma reivindicação personalizada. Digite o uid do valor na caixa suspensa Tipo de solicitação de entrada
• user_principal: Esta é uma reivindicação personalizada. Digite o valor user_main na caixa suspensa Tipo de solicitação de entrada

Rollover de Certificado Automático do ADFS

• A rollover automática de certificado é suportada para UCCX 11.6.1 e superior. [Isso foi corrigido no UCCX 11.6 atualizando a biblioteca do Fedlet para a versão 14.0]

Autenticação Kerberos (Autenticação Integrada do Windows)

A IWA (Integrated Windows Authentication, Autenticação integrada do Windows) fornece um mecanismo para autenticação de usuários, mas não permite que as credenciais sejam transmitidas pela rede. Quando você habilita a autenticação integrada do Windows, ela funciona com base em tíquetes para permitir que os nós que se comunicam através de uma rede não segura provem sua identidade entre si de forma segura. Permite que os usuários façam login em um domínio após fazer login em seus computadores Windows. 

Observação: a autenticação Kerberos é suportada somente a partir de 11.6 e acima.

Os usuários de domínio que já estão conectados ao controlador de domínio (DC) serão conectados sem interrupções nos clientes SSO sem a necessidade de inserir novamente as credenciais.  Para usuários que não são do domínio, o IWA retorna ao NTLM (New Technology Local Area Network Manager) e a caixa de diálogo de login é exibida. A qualificação para IdS com autenticação IWA é feita com Kerberos em relação ao ADFS 3.0.

Etapa 1. Abra o prompt de comando do Windows e execute como usuário Admin para registrar o serviço http com o comando setspn 

             setspn -s http/<ADFS url> <domain>\<account name> .

Etapa 2. Desative a autenticação de formulário e ative a autenticação do Windows para sites da Intranet. Vá para Gerenciamento ADFS > Políticas de autenticação > Autenticação primária > Configurações globais > Editar. Em Intranet, certifique-se de que somente a autenticação do Windows esteja marcada (Desmarque a autenticação do formulário).

Configuração do Microsoft Internet Explorer para suporte do IWA

Etapa 1. Verifique se Internet Explorer > Advanced > Enable Integrated Windows Authentication está marcado.

Etapa 2. O URL do ADFS precisa ser adicionado a Segurança >Zonas de Intranet > Sites (winadcom215.uccx116.com é URL do ADFS)

Etapa 3. Certifique-se de que Internet Explorer > Security > Local Intranet > Security Settings > User Authentication - Logon esteja configurado para usar as credenciais de login para sites de intranet.

Configuração necessária para o suporte do Mozilla Firefox para IWA

Etapa 1. Entre no modo de configuração para o Firefox. Abra o Firefox e digite about:config no URL. Aceite a declaração de riscos.

Etapa 2. Procure ntlm e ative a rede.automatic-ntlm-auth.allow-non-fqdn e defina-a como true.

Etapa 3. Defina network.automatic-ntlm-auth.trust-uris para o domínio ou explicitamente o URL do ADFS.

Configuração necessária para o suporte do Google Chrome para IWA

O Google Chrome no Windows usa as configurações do Internet Explorer, portanto, configure na caixa de diálogo Ferramentas >Opções da Internet do Internet Explorer ou em Painel de Controle em Opções da Internet na subcategoria Rede e Internet.

Configuração adicional para SSO:

Este documento descreve a configuração do aspecto IdP para SSO para integração com o Cisco Identity Service. Para obter mais detalhes, consulte os guias de configuração de produtos individuais:

• UCCX
• UCCE
• PCCE

Verificar

Este procedimento é usado para determinar se a confiança da terceira parte confiável é estabelecida corretamente entre o Cisco IdS e o IDP.

• No navegador, insira o URL https://<ADFS_FQDN>/adfs/ls/IdpInitiatedSignOn.aspx?loginToRp=<IDS_FQDN>
• O ADFS fornecerá o formulário de login. Isso estará disponível quando a configuração acima estiver correta.
• Na autenticação bem-sucedida, o navegador deve redirecionar para https://<IDS_FQDN>:8553/ids/saml/response e uma página de lista de verificação será exibida.

Note: A página da lista de verificação que aparece como parte do processo de verificação não é um erro, mas uma confirmação de que a confiança foi estabelecida corretamente.

Troubleshoot

Para solucionar problemas, consulte - https://www.cisco.com/c/en/us/support/docs/customer-collaboration/unified-contact-center-express/200662-ADFS-IdS-Troubleshooting-and-Common-Prob.html

   

URLs de desvio/recuperação de SSO do UCCX

• URL do Cisco Unified CCX Administration:https://<IP_or_FQDN>/appadmin/recovery_login.htm
• URL para a capacidade de serviço do Cisco Unified CCX:https://<IP_or_FQDN>/uccxservice/recovery_login.htm

Desabilitando SSO

• GUI: Navegue até CCX Administration> Single Sign-On (SSO) > Disable (Administração CCX> Logon único (SSO) > Disable (Desabilitar)
• CLI:set authmode non_sso (este comando deve desativar o SSO para Pub e Sub - pode ser executado de um dos nós UCCX no caso de um cluster de alta disponibilidade (HA))

Capturas de tela

Administração do CCX - Non_SSO:

Administração CCX - SSO habilitado:

Login Finesse - Não SSO:

Login Finesse - SSO ativado:

CUIC - Non_SSO:

CUIC - SSO ativado: