Appendice

Configurazione del servizio di autenticazione XSP (con mTLS)

Completare le procedure in questa Appendice per configurare il servizio di autenticazione su BroadWorks per l'uso dell'autenticazione mTLS. Nei casi in cui la convalida del token CI (con TLS) non è supportata, l'autenticazione mTLS è obbligatoria, incluse le seguenti istanze:

  • Se si utilizza R21SP1

  • Se si utilizza R22 o superiore e sono più organizzazioni Webex che eseguono lo stesso server XSP


Se si utilizza R22 o superiore e non si dispone di più organizzazioni Webex che eseguono lo stesso server XSP, è consigliabile la convalida del token CI (con TLS) per il servizio di autenticazione. Per informazioni dettagliate, vedere Configurazione del servizio di autenticazione (con convalida token CI) nel capitolo Distribuzione di Webex per BroadWorks.

Installa servizio di autenticazione

Su BroadWorks 21SP1, il servizio di autenticazione è un'applicazione predefinita. Installarlo completando le seguenti operazioni:

  1. Scaricare authenticationService_1.0.war (risorsa applicazione Web) da Xchange (https://xchange.broadsoft.com/node/499012).

    Su ciascun XSP utilizzato con Webex, effettuare le seguenti operazioni:

  2. Copiare il file .war in una posizione temporanea su XSP, ad esempio /tmp/

  3. Installare l'applicazione del servizio di autenticazione con il seguente contesto CLI e comando:

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

Configura servizio di autenticazione

I token a lungo termine BroadWorks vengono generati e convalidati dal servizio di autenticazione ospitato su XSP.

Requisiti

  • I server XSP che ospitano il servizio di autenticazione devono disporre di un'interfaccia mTLS configurata.

  • Gli XSP devono condividere le stesse chiavi per la crittografia/decrittografia di token broadworks lunghi. La copia di queste chiavi su ciascun XSP è un processo manuale.

  • Gli XSP devono essere sincronizzati con NTP.

Panoramica sulla configurazione

La configurazione base sugli XSP include:

  • Distribuire il servizio di autenticazione.

  • Configurare la durata del token su almeno 60 giorni (lasciare l'emittente come BroadWorks).

  • Generare e condividere le chiavi RSA su XSP.

  • Fornire l'URL authService al contenitore Web.

Distribuzione del servizio di autenticazione su XSP

Su ciascun XSP utilizzato con Webex:

  1. Attivare l'applicazione del servizio di autenticazione sul percorso /authService(è necessario utilizzare questo percorso):

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

    (dove <version> È 1.0 per l'applicazione sistema su 21SP1).

  2. Distribuire l'applicazione:

    XSP_CLI/Maintenance/ManagedObjects> deploy application /authService

Configurazione della durata del token

  1. Controllare la configurazione token esistente (ore):

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

  2. Impostare la durata su 60 giorni (il massimo è 180 giorni):

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

Genera e condividi chiavi RSA

  • È necessario utilizzare le stesse coppie di chiavi pubbliche/private per la crittografia/decrittografia di token in tutte le istanze del servizio di autenticazione.

  • La coppia di chiavi viene generata dal servizio di autenticazione quando viene richiesto per la prima volta di emettere un token.

A causa di questi due fattori, è necessario generare chiavi su un XSP e copiarle su tutti gli altri XSP.


Se si scorrere le chiavi o modificare la lunghezza della chiave, è necessario ripetere la seguente configurazione e riavviare tutti gli XSP.

  1. Selezionare un XSP da utilizzare per la generazione di una coppia di chiavi.

  2. Utilizzare un client per richiedere un token crittografato da tale XSP, richiedendo il seguente URL dal browser del client:

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

    (Viene generata una coppia privata/chiave pubblica su XSP, se non ne esiste già una)

  3. (solo 21SP1) Controllare la posizione della chiave configurabile utilizzando il comando seguente:

    XSP_CLI/Applications/authenticationService_1.0/KeyManagement> get

  4. (solo 21SP1) Prendere nota dei dati restituiti fileLocation.

  5. (solo 21SP1) Copia intera fileLocation directory, contenente public e private le directory secondarie, a tutti gli altri XSP.

Fornire l'URL authService al contenitore Web

Il container Web di XSP richiede l'URL authService in modo da poter convalidare i token.

Su ciascuno dei XSP:

  1. Aggiungere l'URL del servizio di autenticazione come servizio di autenticazione esterno per lo strumento di comunicazione BroadWorks:

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

  2. Aggiungere l'URL del servizio di autenticazione al container:

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

    Ciò consente a Webex di utilizzare il servizio di autenticazione per convalidare i token presentati come credenziali.

  3. Controllare il parametro con get.

  4. Riavviare XSP.

Configurazione dell'attendibilità del servizio di autenticazione (con mTLS)

Configurazione dell'attendibilità (R21 SP1)
  1. Accedere all'hub del partner.

  2. Andare a Impostazioni > Chiamata BroadWorks e fare clic su Scarica certificato CA Webex per ottenere CombinedCertChain.txt sul computer locale.


    Questo file contiene due certificati. È necessario suddividere il file prima di caricarlo su XSP.
  3. Suddividere la catena di certificati in due certificati:

    1. Apri combinedcertchain.txt in un editor di testo.

    2. Selezionare e tagliare il primo blocco di testo, incluse le linee -----BEGIN CERTIFICATE----- e -----END CERTIFICATE----- e incollare il blocco di testo in un nuovo file.

    3. Salva il nuovo file con nome broadcloudroot.txt.

    4. Salva il file originale con nome broadcloudissuing.txt.

      Il file originale ora deve contenere solo un blocco di testo, circondato dalle linee -----BEGIN CERTIFICATE----- e -----END CERTIFICATE-----.

  4. Copiare entrambi i file di testo in una posizione temporanea sul XSP che si sta proteggendo, ad esempio /tmp/broadcloudroot.txt e /tmp/broadcloudissuing.txt.

  5. Accedere a XSP e passare a /XSP_CLI/Interface/Http/ClientAuthentication>

  6. Eseguire il comando get e leggere il chainDepth.

    (chainDepth è 1 per impostazione predefinita, che è troppo basso per la catena di Webex con due certificati)

  7. Se il valore chainDepth non è già maggiore di 2, eseguire set chainDepth 2.

  8. (Opzionale) Correre help updateTrust per visualizzare i parametri e il formato dei comandi.

  9. Caricare i file del certificato in nuovi trust anchor:

    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 sono alias di esempio per gli trust anchor; è possibile utilizzare il proprio.
  10. Confermare che entrambi i certificati siano caricati:

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

Configurazione dell'attendibilità (R22 e successive)

  1. Accedere a Control Hub con l'account dell'amministratore del partner.

  2. Andare a Impostazioni > Chiamata BroadWorks e fare clic su Scarica certificato CA Webex per ottenere CombinedCertChain.txt sul computer locale.


    Questo file contiene due certificati. È necessario suddividere il file prima di caricarlo su XSP.
  3. Suddividere la catena di certificati in due certificati:

    1. Apri combinedcertchain.txt in un editor di testo.

    2. Selezionare e tagliare il primo blocco di testo, incluse le linee -----BEGIN CERTIFICATE----- e -----END CERTIFICATE----- e incollare il blocco di testo in un nuovo file.

    3. Salva il nuovo file con nome broadcloudroot.txt.

    4. Salva il file originale con nome broadcloudissuing.txt.

      Il file originale ora deve contenere solo un blocco di testo, circondato dalle linee -----BEGIN CERTIFICATE----- e -----END CERTIFICATE-----.

  4. Copiare entrambi i file di testo in una posizione temporanea sul XSP che si sta proteggendo, ad esempio /tmp/broadcloudroot.txt e /tmp/broadcloudissuing.txt.

  5. (Opzionale) Correre help UpdateTrust per visualizzare i parametri e il formato dei comandi.

  6. Caricare i file del certificato in nuovi trust anchor:

    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 sono alias di esempio per gli trust anchor; è possibile utilizzare il proprio.
  7. Confermare che gli ancoraggi siano aggiornati:

    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]

(Opzione) Configurare mTLS a livello di interfaccia/porta HTTP

È possibile configurare mTLS a livello di interfaccia/porta HTTP o su base per applicazione Web.

Il modo in cui si abilita mTLS per l'applicazione dipende dalle applicazioni che si ospitano su XSP. Se si stanno ospitando più applicazioni che richiedono mTLS, è necessario abilitare mTLS sull'interfaccia. Se è necessario proteggere una sola delle applicazioni che utilizzano la stessa interfaccia HTTP, è possibile configurare mTLS a livello di applicazione.

Quando si configura mTLS a livello di interfaccia/porta HTTP, mTLS è richiesto per tutte le applicazioni Web ospitate a cui si accede tramite questa interfaccia/porta.

  1. Accedere a XSP di cui si sta configurando l'interfaccia.

  2. Passa a XSP_CLI/Interface/Http/HttpServer> ed eseguire il get per visualizzare le interfacce.

  3. Per aggiungere un'interfaccia e richiedere l'autenticazione del client (che corrisponde a mTLS):

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

    Per informazioni dettagliate, vedere la documentazione CLI XSP. In base alle prime informazioni, true protegge l'interfaccia con TLS (il certificato del server viene creato se richiesto) e la seconda true forza l'interfaccia a richiedere l'autenticazione del certificato client (insieme sono mTLS).

Ad esempio:

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

In questo esempio, mTLS (Client Auth Req = true) è abilitato su 192.0.2.7 porta 444. TLS abilitato il 192.0.2.7 porta 443.

(Opzione) Configurare mTLS per applicazioni Web specifiche

È possibile configurare mTLS a livello di interfaccia/porta HTTP o su base per applicazione Web.

Il modo in cui si abilita mTLS per l'applicazione dipende dalle applicazioni che si ospitano su XSP. Se si stanno ospitando più applicazioni che richiedono mTLS, è necessario abilitare mTLS sull'interfaccia. Se è necessario proteggere una sola delle applicazioni che utilizzano la stessa interfaccia HTTP, è possibile configurare mTLS a livello di applicazione.

Quando si configura mTLS a livello di applicazione, mTLS è richiesto per tale applicazione indipendentemente dalla configurazione dell'interfaccia del server HTTP.

  1. Accedere a XSP di cui si sta configurando l'interfaccia.

  2. Passa a XSP_CLI/Interface/Http/SSLCommonSettings/ClientAuthentication/WebApps> ed eseguire il get per visualizzare le applicazioni in esecuzione.

  3. Per aggiungere un'applicazione e richiedere l'autenticazione del client (che significa lo stesso di mTLS):

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

    Per informazioni dettagliate, vedere la documentazione CLI XSP. I nomi delle applicazioni sono elencati in questo elenco. L'icona true in questo comando abilita mTLS.

Ad esempio:

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

Il comando di esempio aggiunge l'applicazione AuthenticationService alla versione 192.0.2.7:443 e richiede che a tale applicazione sia richiesta e autenticata dal client.

Controlla con get:

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

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

Requisiti di certificato aggiuntivi per l'autenticazione TLS reciproca con AuthService

Webex interagisce con il servizio di autenticazione su una (autenticazione) TLS reciproca connessione autenticata. Ciò significa che Webex presenta un certificato client e il XSP deve convalidarlo. Per garantire l'attendibilità di questo certificato, utilizzare la catena di certificati CA Webex per creare un trust anchor su XSP (o proxy). La catena di certificati è disponibile per il download tramite Partner Hub:

  1. Andare a Impostazioni > chiamata BroadWorks.

  2. Fare clic sul collegamento per il download del certificato.


È possibile ottenere la catena di certificati anche da https://bwks-uap.webex.com/assets/public/CombinedCertChain.txt.

I requisiti esatti per la distribuzione di questa catena di certificati CA Webex dipendono dalla distribuzione dei XSP pubblici:

  • Tramite un proxy di bridging TLS

  • Tramite un proxy pass-through TLS

  • Direttamente a XSP

Il diagramma seguente riepiloga i punti in cui la catena di certificati CA Webex deve essere distribuita in questi tre casi.

Requisiti del certificato TLS reciproca per il proxy con bridge TLS

  • Webex presenta un certificato client firmato dall'autorità di certificazione Webex nel proxy.

  • La catena di certificati CA Webex viene distribuita sull'archivio di attendibilità del proxy, pertanto il proxy considera attendibile il certificato client.

  • Anche il certificato del server XSP firmato pubblicamente viene caricato nel proxy.

  • Il proxy presenta un certificato del server firmato pubblicamente in Webex.

  • Webex considera attendibile la CA pubblica che ha firmato il certificato del server del proxy.

  • Il proxy presenta un certificato del client firmato internamente agli XSP.

    Questo certificato deve avere il campo dell'estensione x509.v3 Utilizzo chiave estesa compilato con BroadWorks OID 1.3.6.1.4.1.6431.1.1.8.2.1.3e lo scopo dell'autorizzazione del client TLS. Ad esempio.:

    X509v3 extensions:

    X509v3 Extended Key Usage:

    1.3.6.1.4.1.6431.1.1.8.2.1.3, TLS Web Client
                  Authentication 

    Quando si generano certificati del client interno per il proxy, tenere presente che i certificati SAN non sono supportati. I certificati del server interno per XSP possono essere SAN.

  • Gli XSP considerano attendibile la CA interna.

  • Gli XSP presentano un certificato server firmato internamente.

  • Il proxy considera attendibile la CA interna.

Requisiti del certificato TLS reciproca per il proxy passizzato TLS o XSP in DMZ

  • Webex presenta un certificato client firmato dall'Autorità di certificazione Webex sul server XSP.

  • La catena di certificati CA Webex viene distribuita sull'archivio di attendibilità degli XSP, pertanto i criteri XSP 4.5 444 45 45 45 50 40 40 50 000 certificati sono attendibili per i client.

  • Anche il certificato del server XSP firmato pubblicamente viene caricato negli XSP.

  • Gli XSP presentano certificati server firmati pubblicamente a Webex.

  • Webex considera attendibile la CA pubblica che ha firmato i certificati del server XSP.