O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve a configuração do Identity Provider (IdP) para o Cisco Identity Service (IdS) a fim de habilitar o Single Sign On (SSO).
A Cisco recomenda que você tenha conhecimento destes tópicos:
Observação: este documento faz referência ao UCCX nas capturas de tela e nos exemplos, no entanto, a configuração é semelhante com relação ao Cisco IdS (UCCX/UCCE/PCCE) e ao IdP.
Este documento não se restringe a versões de software e hardware específicas.
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Modelos de implantação do Cisco IdS
Produto |
Implantação |
UCCX |
Co-residente |
PCCE |
Co-residente com CUIC (Cisco Unified Intelligence Center) e LD (Live Data) |
UCCE |
Co-residente com CUIC e LD para implantações de 2k. Autônomo para implantações de 4k e 12k. |
A Cisco fornece muitos serviços em 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 encontrar e gerenciar contatos de qualquer um dos aplicativos e dispositivos da Cisco, aproveite todas as fontes possíveis (Diretório corporativo, Outlook, contatos móveis, Facebook, LinkedIn, Histórico) e faça com que eles sejam renderizados de uma maneira padrão e consistente que forneça as informações necessárias para saber sua disponibilidade e como contatá-los melhor.
O SSO com SAML (Security Assertion Markup Language) é voltado para esse requisito. O SAML/SSO oferece aos usuários a capacidade de fazer login em vários dispositivos e serviços por meio de uma identidade comum de conta e autorização chamada IdP. A funcionalidade de SSO está disponível no UCCX/UCCE/PCCE 11.5 em diante.
O Cisco IdS suporta apenas autenticação de IdPs baseada em formulário.
Consulte estes artigos do MSDN para saber como habilitar a Autenticação de Formulário no ADFS.
Observação: o Cisco IdS 11.6 e posterior suporta autenticação Kerberos e baseada em formulário. Para que a autenticação Kerberos funcione, você deve desabilitar a autenticação baseada em Formulário.
Para integração e para permitir que os aplicativos usem o Cisco IdS para SSO, execute a troca de metadados entre o IdS e o IdP.
sp.xml
.Settings
, navegue até IdS Trust
na página Gerenciamento de IdS.
Este é o procedimento para carregar os metadados de IdS e adicionar Regras de reivindicação. Isso é descrito para ADFS 2.0 e 3.0.
Etapa 1. No servidor ADFS, navegue até Start > All Programs > Administrative Tools > ADFS 2.0 Management
,conforme mostrado na imagem:
Etapa 2. Navegue até Add ADFS 2.0 > Trust Relationship > Relying Party Trust
,conforme mostrado na imagem:
Etapa 3. Como mostrado na imagem, escolha a opção Import data about the relying party from a file
.
Etapa 4. Conclua o estabelecimento da Terceira Parte Confiável.
Etapa 5. Nas propriedades do Objeto de Confiança da Terceira Parte Confiável, escolha o Identifier
guia.
Etapa 6. Defina o identificador como o nome de host totalmente qualificado do Cisco Identity Server a partir do qual sp.xml
é baixado.
Passo 7. Clique com o botão direito do mouse em Confiança da Terceira Parte Confiável e, em seguida, clique em Edit Claim Rules
.
Você deve adicionar duas regras de declaração, uma é quando os atributos LDAP (Lightweight Diretory Access Protocol) são correspondidos e a segunda é por meio de regras de declaração personalizadas.
uid - Este atributo é necessário para os aplicativos para identificar o usuário autenticado.
user_principal - Este atributo é necessário para o Cisco IdS identificar o território do usuário autenticado.
Regra de reivindicação 1:
Adicionar uma regra pelo nome NameID
do tipo (enviar os valores do atributo LDAP como declarações):
User-Principal-Name
para user_principal
(minúsculo)userId
para usuários do aplicativo para fazer login e mapeá-lo para uid
(minúsculo)
Exemplo de configuração quando SamAccountName
deve ser usado como a ID de usuário:
SamAccountName
para uid
.User-Principal-Name
para user_principal
.Exemplo de configuração quando UPN
deve ser usado como a ID de usuário:
User-Principal-Name
para uid
.User-Principal-Name
para user_principal
.Exemplo de configuração quando PhoneNumber
deve ser usado como a ID de usuário:
uid
.User-Principal-Name
para user_principal
.
Observação: você deve garantir que o atributo LDAP configurado para o ID de usuário na sincronização LDAP do CUCM corresponda ao que está configurado como o Atributo LDAP para uid
na regra de declaração ADFS NameID
. Isso é para o funcionamento adequado do login do CUIC e do Finesse.
Observação: este documento faz referência a restrições no nome da regra de reivindicação e exibe nomes como NameID, Fully Qualified Domain Name (FQDN) do UCCX, etc. Embora os nomes e campos personalizados possam ser aplicáveis em várias seções, os nomes de exibição e os nomes das regras de declaração são mantidos como padrão durante todo o processo para manter a consistência e para as práticas recomendadas na convenção de nomenclatura.
Regra de reivindicação 2:
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>");
Etapa 8. Clique com o botão direito do mouse em Confiança da Terceira Parte Confiável e, em seguida, clique em Properties
e escolha a guia avançado, conforme mostrado na imagem.
Etapa 9. Como mostrado na imagem, escolha Secure Hash Algorithm (SHA) como SHA-256.
Etapa 10. Clique em OK
.
Etapa 1. No servidor ADFS, navegue até Server Manager > Tools > ADFS Management
.
Etapa 2. Navegue até ADFS > Trust Relationship > Relying Party Trust
.
Etapa 3. Escolha a opção Import data about the relying party from a file
.
Etapa 4. Conclua o estabelecimento da Terceira Parte Confiável.
Etapa 5. Em propriedades do Objeto de Confiança da Terceira Parte Confiável, escolha o Identifier
guia.
Etapa 6. Defina o identificador como o nome de host totalmente qualificado do Cisco Identity Server a partir do qual sp.xml
é baixado.
Passo 7. Clique com o botão direito do mouse em Objeto de Confiança de Terceira Parte Confiável e clique em Edit Claim Rules
.
Você deve adicionar duas regras de declaração, uma é quando os atributos LDAP são correspondidos e a segunda é por meio de regras de declaração personalizadas.
uid - Este atributo é necessário para que os aplicativos identifiquem o usuário autenticado.
user_principal - Este atributo é necessário para o Cisco IdS identificar o território do usuário autenticado.
Regra de reivindicação 1:
Adicionar uma regra pelo nome NameID
do tipo (enviar os valores do atributo LDAP como declarações):
User-Principal-Name
para user_principal
(minúsculo)userId
para que os usuários do aplicativo façam login e mapeiem-no uid
(minúsculo)
Exemplo de configuração quando SamAccountName
deve ser usado como ID de usuário:
SamAccountName
para uid
.User-Principal-Name
para user_principal
.Exemplo de configuração quando o UPN deve ser usado como ID de usuário:
User-Principal-Name
para uid
.User-Principal-Name
para user_principal
.Exemplo de configuração quando PhoneNumber
deve ser usado como a ID de usuário:
telephoneNumber
para uid
.User-Principal-Name
para user_principal
.
Observação: você deve garantir que o atributo LDAP configurado para o ID de usuário na sincronização LDAP do CUCM corresponda ao que está configurado como o Atributo LDAP para uid
na regra de declaração do ADFS NameID. Isso é para a função adequada de login do CUIC e do Finesse.
Observação: Este documento faz referência a restrições no nome da regra de reivindicação e nomes para exibição, como NameID, FQDN do UCCX, etc. Embora os nomes e campos personalizados possam ser aplicáveis em várias seções, os nomes de exibição e os nomes das regras de declaração são mantidos como padrão durante todo o processo para manter a consistência e para as melhores práticas na convenção de nomenclatura.
Regra de reivindicação 2:
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>");
Etapa 8. Clique com o botão direito do mouse em Objeto de Confiança de Terceira Parte Confiável e clique em Properties
e escolha a opção advanced
guia.
Etapa 9. Como mostrado na imagem, escolha SHA como SHA-256.
Etapa 10. Clique em OK
.
Essas etapas são obrigatórias após a Etapa 10.
Etapa 1. Clique em Start
e entre no PowerShell para abrir o windows powershell.
Etapa 2. Adicione o CmdLet do ADFS ao PowerShell com o comando Add-PSSnapin Microsoft.Adfs.Powershell
.
Etapa 3. Execute o comando, Set-ADFSRelyingPartyTrust -TargetName
.
Observação: a Etapa 2 não será necessária se você usar o ADFS 3.0, pois o CmdLet já está instalado como parte da adição de funções e recursos.
Nota: O
O diferencia maiúsculas de minúsculas, portanto, ele corresponde (incluindo maiúsculas e minúsculas) ao que é definido na guia Identificador das propriedades da Relying Party Trust.
Observação: no UCCX versão 12.0, o Cisco IdS oferece suporte a SHA-256. A Relying Party Trust usa SHA-256 para assinar a solicitação SAML e espera a mesma resposta do ADFS.
No caso da Federação no ADFS, em que um ADFS em um determinado domínio fornece autenticação SAML federada para usuários em outros domínios configurados, essas configurações são necessárias.
Para esta seção, o termo ADFS primário se refere ao ADFS que deve ser usado em IdS. O termo ADFS Federado indica aqueles ADFS, cujos usuários podem fazer logon via IdS e, portanto, são os ADFS principais.
Em cada ADFS federado, a Confiança da Terceira Parte Confiável deve ser criada para o ADFS primário e as regras de declaração configuradas conforme mencionado na seção anterior.
Para o ADFS primário, além do Objeto de Confiança da Terceira Parte Confiável para IdS, essa configuração adicional é necessária.
adi Claim Provider Trust
com o ADFS para o qual a federação deve ser configurada.
Na Claim Provider Trust, assegure-se de que o Pass through or Filter an Incoming Claim
as regras são configuradas com a passagem de todos os valores de declaração como a opção:
Incoming Claim Type
dropboxTransient
como a opção para o formato NameID de entradaIncoming Claim Type
dropboxIncoming Claim Type
dropboxNa Terceira Parte Confiável para IdS, adicione Pass though or Filter an Incoming Claim
regras com passagem de todos os valores de declaração como a opção.
Incoming Claim Type
dropboxTransient
como a opção para o formato NameID de entradaIncoming Claim Type
dropboxIncoming Claim Type
dropboxA Substituição automática de certificado é suportada para UCCX 11.6.1 e posterior. (A atualização da biblioteca Fedlet para a versão 14.0 no UCCX 11.6 resolveu esse problema.)
A Autenticação Integrada do Windows (IWA) fornece um mecanismo para a autenticação dos 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 tickets para permitir que os nós se comuniquem em uma rede não segura a fim de comprovar sua identidade entre si de maneira segura. Ele permite que os usuários façam login em um domínio após o login em suas máquinas Windows.
Observação: a autenticação Kerberos é suportada somente a partir da versão 11.6 e posterior.
Os usuários de domínio que já estão conectados ao controlador de domínio (DC) estão conectados perfeitamente aos clientes SSO sem a necessidade de inserir novamente as credenciais. Para usuários que não sejam do domínio, o IWA retorna ao Gerenciador de rede local de nova tecnologia (NTLM) e a caixa de diálogo de login é exibida. A qualificação para IdS com autenticação IWA é feita com Kerberos contra ADFS 3.0.
Etapa 1. Abra o prompt de comando do Windows e execute como um usuário Admin para registrar o serviço HTTP no setspn
comando setspn -s http/
.
Etapa 2. Desabilite a Autenticação de Formulário e habilite a Autenticação do Windows para sites da Intranet. Navegue até ADFS Management > Authentication Policies > Primary Authentication > Global Settings > Edit
. Em Intranet, certifique-se de que apenas a Autenticação do Windows esteja marcada (desmarque Autenticação de formulário).
Etapa 1. Assegure que Internet Explorer > Advanced > Enable Integrated Windows Authentication
está marcado.
Etapa 2. A URL do ADFS deve ser adicionada a Security > Intranet zones > Sites
(winadcom215.uccx116.com
é o URL do ADFS).
Etapa 3. Assegure queInternet Explorer > Security > Local Intranet > Security Settings > User Authentication - Logon
está configurado para usar as credenciais de login para sites da intranet.
Etapa 1. Entre no modo de configuração para o Firefox. Abra o Firefox e digite about:config
na URL. Aceite a declaração de riscos.
Etapa 2. Procurar ntlm
e habilitar a network.automatic-ntlm-auth.allow-non-fqdn
e defina como verdadeiro.
Etapa 3. Defina o network.automatic-ntlm-auth.trusted-uris
ao domínio ou explicitamente à URL do ADFS.
O Google Chrome no Windows usa as configurações do Internet Explorer, então configure no Internet Explorer Tools > Internet Options
ou no Painel de Controle, em Internet Options
dentro da subcategoria Network and Internet
.
Este documento descreve a configuração do aspecto IdP para SSO a fim de integrar com o Cisco IdS. Para obter mais detalhes, consulte os guias de configuração de produtos individuais:
Este procedimento é usado para determinar se o Objeto de Confiança da Terceira Parte Confiável está estabelecido corretamente entre o Cisco IdS e o IDP.
Observação: A página Lista de Verificação que aparece como parte do processo de verificação não é um erro, mas uma confirmação de que a relação de confiança foi estabelecida corretamente.
Para obter informações sobre solução de 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.
CCX Administration > Single Sign-On (SSO) > Disable
.set authmode non_sso
(esse comando deve desabilitar o SSO para Pub e Sub - pode ser executado de qualquer um dos nós do UCCX no caso de um cluster de alta disponibilidade (HA)).
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
24-Aug-2021 |
Versão inicial |