Apêndice

Configurar o serviço de autenticação XSP (com mTLS)

Conclua os procedimentos neste apêndice para configurar o serviço de autenticação no BroadWorks para usar a autenticação mTLS. Em ocorrências onde a Validação de Token CI (com TLS) não é suportada, a autenticação mTLS é obrigatória, incluindo as seguintes ocorrências:

  • Se você estiver executando R21SP1

  • Se você estiver executando R22 ou superior e várias organizações Webex executando o mesmo servidor XSP


Se você estiver executando o R22 ou superior e não tiver várias organizações Webex executando o mesmo servidor XSP, a Validação de Token CI (com TLS) é recomendada para o Serviço de Aut.

Instalar o serviço de autenticação

No BroadWorks 21SP1, o serviço de autenticação é um aplicativo não-planejado. Instale-o concluindo os seguintes passos:

  1. Baixe authenticationService_1 arquivo authenticationService_1.war (recurso de aplicativo da web) do Xchange (https://xchange.broadsoft.com/node/499012).

    Em cada XSP usado com Webex, faça o seguinte:

  2. Copie o arquivo .war para um local temporário no XSP, como /tmp/

  3. Instale o aplicativo do serviço de autenticação com o seguinte contexto e comando CLI:

    XSP_CLI/Maintenance/ManagedObjects> install application /tmp/authenticationService_1.0.war

Configurar o serviço de autenticação

Tokens de longa duração do BroadWorks são gerados e validados pelo serviço de autenticação hospedado nos seus XSPs.

Requisitos

  • Os servidores XSP que organizam o Serviço de Autenticação devem ter uma interface mTLS configurada.

  • XSPs devem compartilhar as mesmas chaves para criptografar/descriptografar tokens vivos do BroadWorks. Copiar essas chaves para cada XSP é um processo manual.

  • XSPs deve ser sincronizado com NTP.

Visão geral da configuração

A configuração essencial nos seus XSPs inclui:

  • Implante o serviço de autenticação.

  • Configure a duração do token para, pelo menos, 60 dias (deixe o emissor como BroadWorks).

  • Gere e compartilhe as chaves RSA em XSPs.

  • Forneça a URL do authService para o recipiente da web.

Implantar o serviço de autenticação no XSP

Em cada XSP usado com o Webex:

  1. Ative o aplicativo do serviço de autenticação no caminho /authService(você deve usar este caminho):

    XSP_CLI/Maintenance/ManagedObjects> activate application authenticationService <version> /authService

    (onde <version> É 1.0 para o aplicativo não-manado em 21SP1).

  2. Implemente o aplicativo:

    XSP_CLI/Maintenance/ManagedObjects> deploy application /authService

Configurar a duração do token

  1. Verifique a configuração de token existente (horas):

    Em 21SP1: XSP_CLI/Applications/authenticationService_1.0/TokenManagement> get

  2. Definir a duração para 60 dias (máx é de 180 dias):

    Em 21SP1: XSP_CLI/Applications/authenticationService_1.0/TokenManagement> set tokenDuration 1440

Gerar e compartilhar as chaves RSA

  • Você deve usar os mesmos pares de chaves públicas/privadas para criptografia/descriptografia de tokens em todas as instâncias do serviço de autenticação.

  • O par de chaves é gerado pelo serviço de autenticação quando primeiro é necessário para emitir um token.

Devido a esses dois fatores, você precisa gerar chaves em um XSP, então copie-as para todos os outros XSPs.


Se você altere as teclas ou o comprimento da chave, você precisará repetir a seguinte configuração e reiniciar todos os XSPs.

  1. Selecione um XSP a ser usado para gerar um par de chaves.

  2. Use um cliente para solicitar um token criptografado desse XSP, solicitando a seguinte URL no navegador do cliente:

    https://<XSP-IPAddress>/authService/token?key=BASE64URL(clientPublicKey)

    (Isso gera um par de chaves pública/privada no XSP, se já não havia um)

  3. (apenas 21SP1) Verifique a localização da chave configurável usando o seguinte comando:

    XSP_CLI/Applications/authenticationService_1.0/KeyManagement> get

  4. (apenas 21SP1) Tome nota do retornado fileLocation.

  5. (apenas 21SP1) Copie o todo fileLocation diretório, que contém public e private subdiretos, para todos os outros XSPs.

Forneça a URL do authService para o recipiente da web

O recipiente da web do XSP precisa da URL do authService para que ele possa validar tokens.

Em cada um dos XSPs:

  1. Adicione a URL do serviço de autenticação como um serviço de autenticação externa para o utilitário BroadWorks Communications:

    XSP_CLI/System/CommunicationUtility/DefaultSettings/ExternalAuthentication/AuthService> set url http://127.0.0.1/authService

  2. Adicione a URL do serviço de autenticação ao recipiente:

    XSP_CLI/Maintenance/ContainerOptions> add tomcat bw.authservice.authServiceUrl http://127.0.0.1/authService

    Isso permite Cisco Webex usar o serviço de autenticação para validar os tokens apresentados como credenciais.

  3. Verifique o parâmetro com get.

  4. Reinicie o XSP.

Configurar o Serviço de Autenticação confiável (com mTLS)

Configurar confiança (R21 SP1)
  1. Entrar no Hub de parceiros.

  2. Vá para Configurações > chamada BroadWorks e clique em Baixar o certificado de CA Webex para obterCombinedCertChain.txt no seu computador local.


    Este arquivo contém dois certificados. Você precisa dividir o arquivo antes de enviá-lo aos XSPs.
  3. Divida a cadeia de certificados em dois certificados:

    1. Abrir combinedcertchain.txt em um editor de texto.

    2. Selecione e corte o primeiro bloco de texto, incluindo as linhas -----BEGIN CERTIFICATE----- e -----END CERTIFICATE----- e colar o bloco de texto em um novo arquivo.

    3. Salvar o novo arquivo como broadcloudroot.txt.

    4. Salvar o arquivo original como broadcloudissuing.txt.

      O arquivo original agora deve ter apenas um bloco de texto, entre as linhas -----BEGIN CERTIFICATE----- e -----END CERTIFICATE-----.

  4. Copie ambos os arquivos de texto para um local temporário no XSP que você está se localizando, por exemplo. /tmp/broadcloudroot.txt e /tmp/broadcloudissuing.txt.

  5. Faça login no XSP e navegue até /XSP_CLI/Interface/Http/ClientAuthentication>

  6. Execute o get comando e leia o chainDepth.

    (chainDepth é 1 por padrão, o que é muito baixo para a cadeia Webex, que tem dois certificados)

  7. Se a cadeiaDepth não for maior que 2, execute set chainDepth 2.

  8. (Opcional) Executar help updateTrust para ver os parâmetros e o formato de comando.

  9. Carregue os arquivos de certificados para novas âncoras de confiança:

    XSP_CLI/Interface/Http/ClientAuthentication/Trusts> updateTrust webexclientroot /tmp/broadcloudroot.txt

    XSP_CLI/Interface/Http/ClientAuthentication/Trusts> updateTrust webexclientissuing /tmp/broadcloudissuing.txt


    webexclientroot e webexclientissuing são exemplos de apelidos para âncoras de confiança; você pode usar seus próprios.
  10. Confirme se ambos os certificados foram carregados:

    /XSP_CLI/Interface/Http/ClientAuthentication/Trusts> get

Configurar o Trust (R22 e posterior)

  1. Entre no Control Hub com sua conta de administrador de parceiro.

  2. Vá para Configurações > chamada BroadWorks e clique em Baixar o certificado de CA Webex para obterCombinedCertChain.txt no seu computador local.


    Este arquivo contém dois certificados. Você precisa dividir o arquivo antes de enviá-lo aos XSPs.
  3. Divida a cadeia de certificados em dois certificados:

    1. Abrir combinedcertchain.txt em um editor de texto.

    2. Selecione e corte o primeiro bloco de texto, incluindo as linhas -----BEGIN CERTIFICATE----- e -----END CERTIFICATE----- e colar o bloco de texto em um novo arquivo.

    3. Salvar o novo arquivo como broadcloudroot.txt.

    4. Salvar o arquivo original como broadcloudissuing.txt.

      O arquivo original agora deve ter apenas um bloco de texto, entre as linhas -----BEGIN CERTIFICATE----- e -----END CERTIFICATE-----.

  4. Copie ambos os arquivos de texto para um local temporário no XSP que você está se localizando, por exemplo. /tmp/broadcloudroot.txt e /tmp/broadcloudissuing.txt.

  5. (Opcional) Executar help UpdateTrust para ver os parâmetros e o formato de comando.

  6. Carregue os arquivos de certificados para novas âncoras de confiança:

    XSP_CLI/Interface/Http/SSLCommonSettings/ClientAuthentication/Trusts> updateTrust webexclientroot /tmp/broadcloudroot.txt

    XSP_CLI/Interface/Http/SSLCommonSettings/ClientAuthentication/Trusts> updateTrust webexclientissuing /tmp/broadcloudissuing.txt


    webexclientroot e webexclientissuing são exemplos de apelidos para âncoras de confiança; você pode usar seus próprios.
  7. Confirme se as âncoras estão atualizadas:

    XSP_CLI/Interface/Http/SSLCommonSettings/ClientAuthentication/Trusts> get

      Alias   Owner                                   Issuer
    =============================================================================
    webexclientissuing    BroadCloud Commercial Issuing CA – DA3     BroadCloud Commercial Trusted Root CA
    webexclientroot       BroadCloud Commercial Trusted Root CA      BroadCloud Commercial Trusted Root CA[self-signed]

(Opção) Configure o mTLS no nível de interface/porta HTTP

É possível configurar mTLS no nível de interface/porta HTTP ou em uma base de aplicativo por web.

A maneira como você habilita o mTLS para seu aplicativo depende dos aplicativos que você está organizando no XSP. Se você estiver organizando vários aplicativos que exigem mTLS, você deve habilitar mTLS na interface. Se você precisar proteger apenas um dos vários aplicativos que usam a mesma interface HTTP, você pode configurar o mTLS no nível da aplicação.

Ao configurar mTLS no nível de interface/porta HTTP, mTLS é necessário para todos os aplicativos da web hospedados acessados através desta interface/porta.

  1. Entrar no XSP cuja interface você está configurando.

  2. Navegue até XSP_CLI/Interface/Http/HttpServer> e execute o get comando para ver as interfaces.

  3. Para adicionar uma interface e exigir a autenticação do cliente lá (o que significa o mesmo que mTLS):

    XSP_CLI/Interface/Http/HttpServer> add IPAddress Port Name true true

    Consulte a documentação XSP CLI para detalhes. Essencialmente, o primeiro true O segura a interface com TLS (certificado do servidor é criado se necessário) e o segundo true força a interface para exigir a autenticação do certificado do cliente (juntos eles são mTLS).

Por exemplo:

XSP_CLI/Interface/Http/HttpServer> get

Interface Port Name Secure Client Auth Req Cluster Fqdn
         =======================================================
         192.0.2.7 443 xsp01.collab.example.net true false 
         192.0.2.7 444 xsp01.collab.example.net true true

Neste exemplo, mTLS (Client Auth Req = true) está habilitado em 192.0.2.7 porta 444. O TLS está habilitado em 192.0.2.7 porta 443.

(Opção) Configure o mTLS para aplicativos da web específicos

É possível configurar mTLS no nível de interface/porta HTTP ou em uma base de aplicativo por web.

A maneira como você habilita o mTLS para seu aplicativo depende dos aplicativos que você está organizando no XSP. Se você estiver organizando vários aplicativos que exigem mTLS, você deve habilitar mTLS na interface. Se você precisar proteger apenas um dos vários aplicativos que usam a mesma interface HTTP, você pode configurar o mTLS no nível da aplicação.

Ao configurar mTLS no nível de aplicativo, mTLS é necessário para esse aplicativo, independentemente da configuração da interface do servidor HTTP.

  1. Entrar no XSP cuja interface você está configurando.

  2. Navegue até XSP_CLI/Interface/Http/SSLCommonSettings/ClientAuthentication/WebApps> e execute o get para ver quais aplicativos estão sendo executados.

  3. Para adicionar um aplicativo e exigir autenticação do cliente para ele (o que significa o mesmo que mTLS):

    XSP_CLI/Interface/Http/SSLCommonSettings/ClientAuthentication/WebApps> add IPAddress Port ApplicationName true

    Consulte a documentação XSP CLI para detalhes. Os nomes dos aplicativos são enumerados lá. O comando true neste comando permite mTLS.

Por exemplo:

XSP_CLI/Interface/Http/SSLCommonSettings/ClientAuthentication/WebApps> add 192.0.2.7 443 AuthenticationService true

O exemplo de comando adiciona o aplicativo AuthenticationService a 192.0.2.7:443 e requer que ele solicite e autentente os certificados do cliente.

Verificar com get:

XSP_CLI/Interface/Http/SSLCommonSettings/ClientAuthentication/WebApps> get

Interface Ip Port Application Name Client Auth Req
         ===================================================
         192.0.2.7 443 AuthenticationService      true          

Requisitos de certificado adicionais para autenticação TLS mútua contra o AuthService

Cisco Webex interage com o Serviço de Autenticação através de TLS mútuo conexão autenticada. Isso significa que o Webex apresenta um certificado de cliente e o XSP deve validá-lo. Para confiar neste certificado, use a cadeia de certificados CA do Webex para criar um âncora de confiança no XSP (ou proxy). A cadeia de certificados está disponível para download via Partner Hub:

  1. Vá para Configurações > chamada BroadWorks.

  2. Clique no link do certificado de download.


Você também pode obter a cadeia de certificados de https://bwks-uap.webex.com/assets/public/CombinedCertChain.txt.

Os requisitos exatos para a implantação desta cadeia de certificados CA Webex depende de como o seu XSPs voltados ao público são implantados:

  • Através de um proxy de ponte TLS

  • Através de um proxy de passagem TLS

  • Diretamente ao XSP

O diagrama a seguir resume onde a cadeia de certificados ca Webex deve ser implantada nesses três casos.

Requisitos do certificado TLS mútuo para Proxy de ponte TLS

  • O Webex apresenta um certificado de cliente assinado pela CA Webex para o proxy.

  • A cadeia de certificados CA do Webex é implantada no proxy trust store, assim o proxy confia no certificado do cliente.

  • O certificado de servidor XSP assinado publicamente também é carregado no proxy.

  • O proxy apresenta um certificado de servidor assinado publicamente ao Webex.

  • O Webex confia na CA pública que assinou o certificado de servidor do proxy.

  • O proxy apresenta um certificado de cliente assinado internamente para os XSPs.

    Este certificado deve ter o campo de extensão x509.v3 preenchido com o BroadWorks OID 1.3.6.1.4.1.6431.1.1.8.2.1.3 e a finalidade do cliente TLSAuth. E.g.:

    X509v3 extensions:

    X509v3 Extended Key Usage:

    1.3.6.1.4.1.6431.1.1.8.2.1.3, TLS Web Client
                  Authentication 

    Ao gerar certificados de cliente interno para o proxy, observe que os certificados SAN não são suportados. Os certificados do servidor interno para o XSP podem ser SAN.

  • Os XSPs confiam na CA interna.

  • Os XSPs apresentam um certificado de servidor assinado internamente.

  • O proxy confia na CA interna.

Requisitos do certificado TLS mútuo para proxy TLS-pass securário ou XSP no DMZ

  • O Webex apresenta um certificado de cliente assinado pelo Webex CA para os XSPs.

  • A cadeia de certificados ca Webex é implantada no armazenamento de confiança do XSPs, assim os XSPs confiam no certificado do cliente.

  • O certificado de servidor XSP assinado publicamente também é carregado nos XSPs.

  • Os XSPs apresentam certificados de servidor assinados publicamente para o Webex.

  • O Webex confia na CA pública que assinou os certificados do servidor XSPs.