Hub de controle e assinatura única

O registro único (SSO) é um processo de autenticação de sessão ou usuário que permite ao usuário fornecer credenciais para acessar um ou mais aplicativos. O processo autentica os usuários em todos os aplicativos aos quais eles têm direitos. Ele elimina outros avisos quando os usuários alternam de aplicativos durante uma sessão específica.

O protocolo de federação Security Assertion Markup Language (SAML 2.0) é usado para fornecer SSO autenticação entre a nuvem Webex e seu provedor de identidade (IdP).

Perfis

O aplicativo Webex suporta apenas o perfil de usuário SSO navegador da web. No perfil de usuário do SSO da web, o aplicativo Webex suporta as seguintes ligações:

  • POST iniciado por SP -> vinculação de POST

  • REDIRECIONAMENTO iniciado por SP -> vinculação de POST

Formato IDNome

O Protocolo SAML 2.0 é compatível com vários formatos de NameID destinados à comunicação sobre um usuário específico. O aplicativo Webex suporta os seguintes formatos de NameID.

  • urn:oasis:names:tc:SAML:2.0:nameid-format:transient

  • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

  • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

Nos metadados que você carregar do IdP, a primeira entrada será configurada para uso no Webex.

SingleLogout

O aplicativo Webex suporta o perfil de logout único. No aplicativo Webex, um usuário pode finalizar a sessão, que usa o protocolo de logout único SAML para finalizar a sessão e confirmar que finalizou a sessão com o seu IdP. Certifique-se de que seu IdP esteja configurado para SingleLogout.

Integre o Control Hub com o Shibboleth

Os guias de configuração mostram um exemplo específico da integração de SSO, mas não fornecem uma configuração completa de todas as possibilidades. Por exemplo, as etapas de integração de nameid-format urn:oasis:names:tc:SAML:2.0:nameid-format:transient são documentadas. Outros formatos, como urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified ou urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress, funcionarão na integração de SSO, mas estão fora do escopo da nossa documentação.

Configurar esta integração para usuários na sua organização Webex ( incluindo Aplicativo Webex, Webex Meetingse outros serviços administrados no Control Hub). Se seu site Webex estiver integrado no Control Hub, o site Webex herda o gerenciamento de usuários. Se não conseguir acessar Webex Meetings dessa maneira e não for gerenciado no Control Hub, você deverá fazer uma integração separada para habilitar o SSO para o Webex Meetings. (Consulte Configurar o registro único no Webex para obter mais informações sobre a integração de SSO na administração do site.)

As etapas da integração se refere ao Shibboleth 2.4.5 no CentOS 7 com o Tomcat 7 como o servidor da web.

Antes de começar

No SSO e Control Hub, os IdPs devem estar em conformidade com a especificação SAML 2.0. Além disso, os IdPs devem ser configurados da seguinte maneira:

Baixe os metadados Webex para o seu sistema local

1

Na exibição do cliente https://admin.webex.comem , vá para Gerenciamento > Configurações da organização, role até Autenticação e, em seguida, alterne na configuração de Logon único para iniciar o assistente de configuração.

2

Escolha o tipo de certificado para sua organização:

  • Autoassinado pela Cisco —Recomendamos essa escolha. Deixe-nos assinar o certificado, assim você só precisará renová-lo uma vez a cada cinco anos.
  • Assinado por uma autoridade de certificação pública —Mais seguro, mas você precisará atualizar os metadados com frequência (a menos que seu fornecedor IdP ofereça suporte a âncoras de confiança).

Os âncoras de confiança são as chaves públicas que agem como uma autoridade para verificar o certificado de uma assinatura digital. Para obter mais informações, consulte a documentação do IdP.

3

Baixe o arquivo de metadados.

O nome do arquivo de metadados Webex é idb-meta--SP.xml .

Configurar a autorização nos arquivos do Shibboleth

Depois de instalar o Shibboleth, será fornecido a você arquivos de configuração com exemplos.

1

Vá para o diretório /opt/shibboleth-idp/conf para acessar os arquivos de exemplo.

2

Decida qual método de autorização usar - por exemplo, o LDAP se vincula ao Active Directory.

3

Edite o arquivo handler.xml da seguinte forma:

Descomente

   urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

Comentário

 urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified
4

Preencha os detalhes do seu e Active Directory para permitir a autenticação. Forneça a configuração para o logon de arquivo.config.

 ShibUserPassAuth { edu.vt.middleware.ldap.jaas.LdapLoginModule required ldapUrl="ldap://ad0a.cisco.net:389" ssl="false" tls="false" baseDn="cn=Users,dc=cisco,dc=net" subtreeSearch="true" userFilter="sAMAccountName={0}" bindDn="cn=Administrator,cn=Users,dc=cisco,dc=net" bindCredential="ThePassword"; };

Configurar componentes do provedor de serviço Shibboleth para a assfirmação SAML

1

Adicione o arquivo que você baixou do SP Webex ao diretório /opt/shibboleth-idp/metadados.

2

Edite o arquivo relying-party.xml ; após a tag DefaultRelyingParty, adicione os detalhes da asserção SAML do Webex.

 <rp:RelyingParty id="https://idbroker.webex.com/ea7c1420-711d-4916-95f8- 22de53230d1e" provider="https://shib9a.cisco.net/idp/shibboleth" defaultSigningCredentialRef="IdPCredential"> <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" includeAttributeStatement="true" assertionProxyCount="PT5M" assertionProxyCount="0" signAssertions="always" encryptAssertions="conditional" encryptNameIds="never" includeConditionsNotBefore="true"/>

Para id, você deve usar o valor EntityID do arquivo de metadados Webex . Substitua a ID do exemplo pelo EntityID da sua organização.

3

Dentro da tag Metadados:MetadadosProvider, adicione o local do arquivo:

  <metadata:MetadataProvider id="IdPMD" xsi:type="metadata:FilesystemMetad ataProvider" metadataFile="/opt/shibboleth-idp/metadata/idp-metadata.xml" maxRefreshDelay="P1D"/>  <metadata:MetadataProvider xsi:type="FilesystemMetadataProvider" xmlns="urn:m ace:shibboleth-idp/metadata File="2.0:metadata" id="ucxn9a" metadataFile="/opt/shibboleth-idp/metad-agreement.xml"/> <metadata:Cisco CUCM Configuration --> <metadata:MetadataProvider xsi:type="FilesystemMetadataProvider" xmlns="urn:m ace:shibboleth-idp/meta  <!-- Configuração do Cisco CI <metadados:MetadataProvider xsi:type="FilesystemMetadataProvider" xmlns="urn:m ace:shibboleth:2.0:metadata" id="CI" metadataFile="/opt/shibboleth-idp/metadata/ idb-meta-ea7c1420-711d-4916-95f8-22de53230d1e-SP.xml" /> </metadados:MetadataProvider>

Os metadados SP vêm de um arquivo no sistema de arquivo Shibboleth, no local onde você carregou os metadados da sua organização Webex .

Configurar os atributos de ass declaração

1

Na seção Conector de dados, especifique onde recuperar atributos sobre seus usuários.

Active Directory, com uma ID de meu LDAP.

  <![CDATA[ (sAMAccountName=$requestContext.principalName) ]]>

2

Na seção Definição de atributo, mantenha o que já está na configuração para transitórioID.

3

Adicione o atributo extra que o SP está esperando e defina o que ele mapeia na fonte do atributo.

Mapeie o e-mail do atributo (atributo de endereço de e-mail no Active Directory) para uid (ID de usuário no Webex).

 <resolver:Dependency ref="MyLDAP"/> <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="uid"/> </resolver:AttributeDefinition

4

Definir qual atributo fornecer para cada acordo SP no arquivo attribute-filter.xml .

Forneça o atributo uid ao Webex que mapeia o endereço de e-mail do usuário.

Solte o uid do atributo no acordo SP com o Webex.

  <afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="https://idbroker.webex.com/ea7c1420-711d-4916-95f8-22de53230d1e" />  <afp:PermitValueRule xsi:type="basic:ANY"/>   <afp:PermitValueRule xsi:type="basic:ANY"/>  <afp:AttributeRule xsi:type="basic:ANY"/>  <afp:AttributeRule> </afp:AttributeFilterPolicy>

A regra que você criou no attribute-resolver.xml deve ter uma política para liberar o atributo mail-attr ao EntityID que corresponde ao Webex.

5

Baixe o arquivo de metadados do servidor do Shibboleth em /opt/shibboleth-idp/metadados. O nome do arquivo é idp-metadados.xml.

Importar os metadados IdP e habilitar registro único um teste

Depois de exportar os metadados Webex , configurar o IdP e baixar os metadados IdP para o sistema local, você estará pronto para importá-los para sua organização Webex a partir do Control Hub.

Antes de começar

Não teste a integração de SSO da interface do fornecedor de identidade (IdP). Nós suportamos apenas os fluxos iniciados provedor de serviços (iniciados pelo SP), então você deve usar o Control Hub SSO teste para essa integração.

1

Escolha uma das opções:

  • Retorne ao Control Hub - página de seleção de certificado em seu navegador e, em seguida, clique em Next .
  • Se o Control Hub não estiver mais aberto na guia do navegador, na exibição do cliente em https://admin.webex.com, vá para Gerenciamento > Configurações da organização, role até Autenticaçãoe então escolha Ações > Importar metadados...
2

Na página Importar metadados do IdP, arraste e solte o arquivo de metadados do IdP na página ou use a opção do navegador de arquivos para localizar e carregar o arquivo de metadados. Clique em Próximo.

Você deve usar a opção Mais segura, se puder. Isso só é possível se o IdP usou uma CA pública para assinar seus metadados.

Em todos os outros casos, você deve usar a opção Menos segura. Isso inclui se os metadados não foram assinados, auto assinados ou assinados por uma CA privada.

Okta não assina os metadados, então você deve escolher Menos seguro para uma integração okta SSO.

3

Selecione Testar configuração de SSO , e quando uma nova guia do navegador for aberta, autentique-se com o IdP iniciando sessão.

Se você receber um erro de autenticação, talvez haja um problema com as credenciais. Verifique o nome de usuário e a senha e tente novamente.

Um erro do aplicativo Webex geralmente significa um problema com a SSO configuração completa. Nesse caso, percorra as etapas novamente, especialmente as etapas em que você copia e cola os metadados do Control Hub na configuração do IdP.

Para ver diretamente a experiência de início de sessão do SSO, você também pode clicar em Copiar URL para a área de transferência nesta tela e colá-la em uma janela privada do navegador. A partir daí, você poderá iniciar sessão com o SSO. Esta etapa para falso positivos devido a um token de acesso que pode estar em uma sessão existente de você ter sido logado.

4

Volte para a guia do navegador do Control Hub.

  • Se o teste foi bem-sucedido, selecione Teste bem-sucedido. A ligue SSO e clique em Próximo.
  • Se o teste foi mal sucedido, selecione Teste malsucedido. Desligue a SSO e clique em Próximo.

A SSO organizador não tem efeito em sua organização, a menos que você escolha a botão de opção nome e ative o SSO.

O que fazer em seguida

Use os procedimentos em Sincronizar usuários okta em Cisco Webex Control Hub se você quiser fazer provisionamento de usuário fora do Okta na nuvem Webex.

Use os procedimentos em Sincronizar os Active Directory Azure em Cisco Webex Control Hub se você quiser fazer o provisionamento de usuário do Azure AD na nuvem Webex.

Você pode seguir o procedimento em Suprimir e-mails automáticos para desativar os e-mails enviados aos novos usuários do aplicativo Webex em sua organização. O documento também contém as melhores práticas para o envio de comunicações aos usuários em sua organização.