Logon único e Control Hub

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 da linguagem de marcação de declaração de segurança (SAML 2.0) é usado para fornecer autenticação de SSO entre a nuvem Webex e seu fornecedor da identidade (IdP).

Perfis

O aplicativo Webex suporta apenas o perfil de SSO do navegador da web. No perfil de SSO do navegador da web, o aplicativo Webex suporta as seguintes associaçõ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ê carrega do IdP, a primeira entrada é configurada para uso no Webex.

SingleLogout

O aplicativo Webex suporta o perfil de logoff único. No aplicativo Webex, um usuário pode finalizar a sessão do aplicativo, que usa o protocolo SAML de logoff único para encerrar a sessão e confirmar que a finalizou com o 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 do 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 or urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress funcionarão para integração de SSO, mas estão fora do escopo da nossa documentação.

Configure esta integração para usuários em sua organização Webex (incluindo Webex App, Webex Meetings e outros serviços administrados no Control Hub). Se o seu site do Webex estiver integrado no Control Hub, o site do Webex herdará o gerenciamento de usuários. Se você não pode acessar o Webex Meetings dessa maneira e ele não é gerenciado no Control Hub, você deve fazer uma integração separada para habilitar o SSO para 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 de integração se referem ao Shibboleth 2.4.5 no CentOS 7 com o Tomcat 7 como servidor Web.

Antes de você 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 do Webex para seu sistema local

1

A partir da exibição do cliente emhttps://admin.webex.com , ir para Gerenciamento > Configurações da organização e role até Autenticação e, em seguida, alterne para Logon único configuração para iniciar o assistente de configuração.

2

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

  • Autoassinado pela Cisco —Recomendamos esta escolha. Deixe-nos assinar o certificado para que você só precise 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 provedor IdP ofereça suporte a âncoras de confiança).

 

As âncoras de confiança são 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-<org-ID> -SP.xml .

Configurar autorização em arquivos Shibboleth

Depois de instalar o Shibboleth, você receberá exemplos de arquivos de configuração.

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, LDAP vincula-se ao Active Directory.

3

Edite o arquivo handler.xml da seguinte forma:

Cancelar comentário

    <!--  Username/password login handler -->
    <ph:LoginHandler xsi:type="ph:UsernamePassword"
                  jaasConfigurationLocation="file:///opt/shibboleth-idp/conf/login.config">  
  <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</ph:AuthenticationMethod>
    </ph:LoginHandler>

Comentário

<ph:LoginHandler xsi:type="ph:RemoteUser"> 
<ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</ph:AuthenticationMethod>
    </ph:LoginHandler>
4

Preencha os detalhes do seu Active Directory para permitir a autenticação. Forneça a configuração para o arquivo login.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ços Shibboleth para asserção SAML

1

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

2

Editar o relying-party.xml arquivo; 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"
                assertionLifetime="PT5M" assertionProxyCount="0"
                signResponses="never" signAssertions="always"
                encryptAssertions="conditional" encryptNameIds="never"
                includeConditionsNotBefore="true"/>
        </rp:RelyingParty>

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

3

Dentro da tag metadados:MetadataProvider, adicione o local do arquivo:

 <metadata:MetadataProvider id="ShibbolethMetadata" xsi:type="metadata:Chaini
ngMetadataProvider">
        <metadata:MetadataProvider id="IdPMD" xsi:type="metadata:FilesystemMetad
ataProvider" metadataFile="/opt/shibboleth-idp/metadata/idp-metadata.xml" maxRefreshDelay="P1D" />
    <!--     Cisco UCXN Configuration               -->
   <metadata:MetadataProvider xsi:type="FilesystemMetadataProvider" xmlns="urn:m
ace:shibboleth:2.0:metadata" id="ucxn9a" metadataFile="/opt/shibboleth-idp/metad
ata/ucxn9a-single-agreement.xml" />
    <!--     Cisco CUCM Configuration               -->
   <metadata:MetadataProvider xsi:type="FilesystemMetadataProvider" xmlns="urn:m
ace:shibboleth:2.0:metadata" id="cucm9a" metadataFile="/opt/shibboleth-idp/metad
ata/cucm9a.cisco.net-single-agreement.xml" />
    <!--     Cisco CI Configuration               
   <metadata: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" />
    </metadata:MetadataProvider>

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

Configurar os atributos de asserção

1

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

Active Directory, com uma ID do MyLDAP.

<resolver:DataConnector id="MyLDAP" xsi:type="dc:LDAPDirectory"
      ldapURL="ldap://ad0a.cisco.net:389"
      baseDN="cn=Users,dc=cisco,dc=net"
      principal="Administrator@cisco.net"
      principalCredential="ThePassword">
        <dc:FilterTemplate>
            <![CDATA[
                (sAMAccountName=$requestContext.principalName)
            ]]>
        </dc:FilterTemplate>
    </resolver:DataConnector>
2

Na seção de definição de atributo, mantenha o que já está na configuração do transientID.

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:AttributeDefinition id="mail-attr" xsi:type="ad:Simple" 
sourceAttributeID="mail">
        <resolver:Dependency ref="MyLDAP" />
        <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="uid" />
     </resolver:AttributeDefinition>
4

Defina qual atributo fornecer a cada contrato SP no arquivo attribute-filter.xml .

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

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

<!--  Release the attributes to cisco CI Cloud  -->
    <afp:AttributeFilterPolicy id="ReleaseToCI">
        <afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" 
value="https://idbroker.webex.com/ea7c1420-711d-4916-95f8-22de53230d1e" />
        <afp:AttributeRule attributeID="transientId">
            <afp:PermitValueRule xsi:type="basic:ANY"/>
        </afp:AttributeRule>
        <afp:AttributeRule attributeID="mail-attr">
            <afp:PermitValueRule 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 Shibboleth em /opt/shibboleth-idp/metadata . O nome do arquivo é idp-metadata.xml .

Importar os metadados IdP e habilitar a logon único centralizada após um teste

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

Antes de você começar

Não teste a integração de SSO da interface do fornecedor de identidade (IdP). Oferecemos suporte apenas para fluxos iniciados pelo provedor de serviços (iniciados por SP), portanto, você deve usar o teste de SSO do Control Hub nessa integração.

1

Escolha uma das opções:

  • Retorne para a página de seleção de certificado do Control Hub no seu navegador e clique em Próximo .
  • Se o Control Hub não estiver mais aberto na guia do navegador, a partir da exibição do cliente emhttps://admin.webex.com , ir para Gerenciamento > Configurações da organização , role até Autenticação e, em seguida, 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 o Mais seguro opção, se possível. Isso só será possível se o IdP tiver usado uma CA pública para assinar os metadados.

Em todos os outros casos, você deve usar o Menos seguro opção. Isso inclui se os metadados não são assinados, autoassinados ou assinados por uma CA privada.


 

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

3

Selecionar Testar a configuração do 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 configuração do SSO. 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 falsos positivos devido a um token de acesso que pode estar em uma sessão existente em que você está conectado.

4

Volte para a guia do navegador do Control Hub.

  • Se o teste foi bem-sucedido, selecione Teste bem-sucedido. Ativar o SSO e clique em Próximo .
  • Se o teste não foi bem-sucedido, selecione Teste malsucedido. Desativar o SSO e clique em Próximo .

 

A configuração do SSO não entra em vigor na sua organização, a menos que você escolha o primeiro botão de opção de opção e ative o SSO.

O que fazer em seguida

Utilize os procedimentos em Sincronizar usuários Okta no Cisco Webex Control Hub se você quiser fazer o provisionamento de usuários do Okta para a nuvem Webex .

Utilize os procedimentos em Sincronizar os usuários do Azure Active Directory no Cisco Webex Control Hub se você quiser fazer o provisionamento de usuários do Azure AD para a nuvem Webex .

Você pode seguir o procedimento em Suprimir os e-mails automatizados para desabilitar os e-mails que são enviados para novos usuários do aplicativo Webex na 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.