apendice

Configurarea serviciului de autentificare XSP (cu mTLS)

Finalizați procedurile din această anexă pentru a configura serviciul de autentificare pe BroadWorks pentru a utiliza autentificarea mTLS. În cazurile în care validarea simbolului CI (cu TLS) nu este acceptată, autentificarea mTLS este obligatorie, inclusiv următoarele instanțe:

  • Dacă executați R21SP1

  • Dacă executați R22 sau o versiune ulterioară și aveți mai multe organizații Webex care se execută pe același server XSP


Dacă executați R22 sau o versiune ulterioară și nu aveți mai multe organizații Webex care execută același server XSP, se recomandă validarea simbolului CI (cu TLS) pentru Serviciul Auth. Pentru detalii, consultați Configurarea serviciului de autentificare (cu validare simbol CI) în capitolul ImplementareWebex pentru BroadWorks.

Instalare serviciu de autentificare

Pe BroadWorks 21SP1, serviciul de autentificare este o aplicație negestionată. Instalați-l completând următorii pași:

  1. Descarca authenticationService_1.0.war (web application resource) fișier de la Xchange (https://xchange.broadsoft.com/node/499012).

    Pe fiecare XSP utilizat cu Webex, procedați astfel:

  2. Copiați fișierul .war într-o locație temporară de pe XSP, ar fi /tmp/

  3. Instalați aplicația serviciu de autentificare cu următorul context și comandă CLI:

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

Configurare serviciu de autentificare

Token-urile BroadWorks de lungă durată sunt generate și validate de serviciul de autentificare găzduit pe XSP-urile dvs.

cerințe

  • Serverele XSP care găzduiesc serviciul de autentificare trebuie să aibă configurată o interfață mTLS.

  • XSP-urile trebuie să partajeze aceleași taste pentru criptarea/decriptarea simbolurilor BroadWorks de lungă durată. Copierea acestor taste la fiecare XSP este un proces manual.

  • XSP-urile trebuie sincronizate cu NTP.

Prezentare generală a configurației

Configurația esențială a XSP-urilor include:

  • Implementați serviciul de autentificare.

  • Configurați durata tokenului la cel puțin 60 de zile (lăsați emitentul ca BroadWorks).

  • Generați și partajați taste RSA prin XSP-uri.

  • Furnizați url-ul authService containerului web.

Implementarea serviciului de autentificare pe XSP

Pe fiecare XSP utilizat cu Webex:

  1. Activarea aplicației serviciului de autentificare pe cale /authService(trebuie să utilizați această cale):

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

    (în cazul în care <version> e 1.0 pentru aplicația negestionată la 21SP1).

  2. Implementați aplicația:

    XSP_CLI/Maintenance/ManagedObjects> deploy application /authService

Configurare durată simbol

  1. Verificați configurația existentă a tokenului (ore):

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

  2. Setați durata la 60 de zile (max. este de 180 de zile):

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

Generarea și partajarea cheilor RSA

  • Trebuie să utilizați aceleași perechi de chei publice/private pentru criptarea/decriptarea token-urilor în toate instanțele serviciului de autentificare.

  • Perechea de chei este generată de serviciul de autentificare atunci când este necesar pentru prima dată să emită un simbol.

Din cauza acestor doi factori, trebuie să generați chei pe un XSP, apoi să le copiați pe toate celelalte XSP-uri.


Dacă aveți taste de ciclu sau modificați lungimea cheii, trebuie să repetați următoarea configurație și să reporniți toate XSP-urile.

  1. Selectați un XSP de utilizat pentru generarea unei perechi de taste.

  2. Utilizați un client pentru a solicita un simbol criptat de la acel XSP, solicitând următorul URL din browserul clientului:

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

    (Acest lucru generează o pereche de chei private / publice pe XSP, dacă nu a existat deja unul)

  3. (numai 21SP1) Verificați locația cheii configurabile utilizând următoarea comandă:

    XSP_CLI/Applications/authenticationService_1.0/KeyManagement> get

  4. (numai 21SP1) Luați act de fileLocation parametru.

  5. (numai 21SP1) Copierea întregului fileLocation director, care conține public și private subdirectoare, către toate celelalte XSP-uri.

Furnizarea adresei URL authService în containerul web

Containerul web XSP are nevoie de ADRESA URL authService, astfel încât să poată valida jetoanele.

Pe fiecare dintre XSP-uri:

  1. Adăugați URL-ul serviciului de autentificare ca serviciu de autentificare externă pentru Utilitarul de comunicații BroadWorks:

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

  2. Adăugați URL-ul serviciului de autentificare la container:

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

    Acest lucru permite Webex să utilizeze serviciul de autentificare pentru a valida simbolurile prezentate ca acreditări.

  3. Verificați parametrul cu get.

  4. Reporniți XSP.

Configurarea serviciului de încredere pentru autentificare (cu mTLS)

Configurare încredere (R21 SP1)
  1. Conectați-vă la Hubul partener.

  2. Accesați Setări > Apelare BroadWorks și faceți clic pe Descărcare certificat CA Webex pentru a obțineCombinedCertChain.txt de pe computerul local.


    Acest fișier conține două certificate. Trebuie să împărțiți fișierul înainte de a-l încărca în XSP-uri.
  3. Împărțiți lanțul de certificate în două certificate:

    1. Deschideți combinedcertchain.txt într-un editor de text.

    2. Selectarea și tăierea primului bloc de text, inclusiv a liniilor -----BEGIN CERTIFICATE----- și -----END CERTIFICATE----- și lipiți blocul text într-un fișier nou.

    3. Salvarea noului fișier ca broadcloudroot.txt.

    4. Salvarea fișierului original ca broadcloudissuing.txt.

      Fișierul original ar trebui să aibă acum un singur bloc de text, înconjurat de linii -----BEGIN CERTIFICATE----- și -----END CERTIFICATE-----.

  4. Copiați ambele fișiere text într-o locație temporară pe XSP-ul pe care îl securizati, de ex. /tmp/broadcloudroot.txt și /tmp/broadcloudissuing.txt.

  5. Conectați-vă la XSP și navigați la /XSP_CLI/Interface/Http/ClientAuthentication>

  6. Executați get comanda și citiți chainDepth parametru.

    (chainDepth este 1 în mod implicit, care este prea mic pentru lanțul Webex care are două certificate)

  7. Dacă lanțulDepth nu este deja mai mare de 2, executați set chainDepth 2.

  8. (Opțional) alerga help updateTrust pentru a vedea parametrii și formatul comenzii.

  9. Încărcați fișierele de certificat în noi ancore de încredere:

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

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


    webexclientroot și webexclientissuing sunt aliasuri de exemplu pentru ancorele de încredere; poți să-ți folosești și tu unul.
  10. Confirmați că ambele certificate sunt încărcate:

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

Configurare încredere (R22 și versiuni ulterioare)

  1. Conectați-vă la Control Hub cu contul de administrator partener.

  2. Accesați Setări > Apelare BroadWorks și faceți clic pe Descărcare certificat CA Webex pentru a obțineCombinedCertChain.txt de pe computerul local.


    Acest fișier conține două certificate. Trebuie să împărțiți fișierul înainte de a-l încărca în XSP-uri.
  3. Împărțiți lanțul de certificate în două certificate:

    1. Deschideți combinedcertchain.txt într-un editor de text.

    2. Selectarea și tăierea primului bloc de text, inclusiv a liniilor -----BEGIN CERTIFICATE----- și -----END CERTIFICATE----- și lipiți blocul text într-un fișier nou.

    3. Salvarea noului fișier ca broadcloudroot.txt.

    4. Salvarea fișierului original ca broadcloudissuing.txt.

      Fișierul original ar trebui să aibă acum un singur bloc de text, înconjurat de linii -----BEGIN CERTIFICATE----- și -----END CERTIFICATE-----.

  4. Copiați ambele fișiere text într-o locație temporară pe XSP-ul pe care îl securizati, de ex. /tmp/broadcloudroot.txt și /tmp/broadcloudissuing.txt.

  5. (Opțional) alerga help UpdateTrust pentru a vedea parametrii și formatul comenzii.

  6. Încărcați fișierele de certificat în noi ancore de încredere:

    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 și webexclientissuing sunt aliasuri de exemplu pentru ancorele de încredere; poți să-ți folosești și tu unul.
  7. Confirmați că ancorele sunt actualizate:

    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țiune) Configurarea mTLS la nivel de interfață HTTP/port

Este posibilă configurarea mTLS la nivel de interfață/port HTTP sau pe bază de aplicație web.

Modul în care activați mTLS pentru aplicația dvs. Dacă găzduiți mai multe aplicații care necesită mTLS, ar trebui să activați mTLS pe interfață. Dacă trebuie doar să securizați una dintre mai multe aplicații care utilizează aceeași interfață HTTP, puteți configura mTLS la nivel de aplicație.

La configurarea mTLS la nivelul interfeței/portului HTTP, mTLS este necesar pentru toate aplicațiile web găzduite accesate prin această interfață/port.

  1. Conectați-vă la XSP a cărui interfață o configurați.

  2. Navigare la XSP_CLI/Interface/Http/HttpServer> și rulați get pentru a vedea interfețele.

  3. Pentru a adăuga o interfață și a solicita autentificarea clientului acolo (ceea ce înseamnă același lucru cu mTLS):

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

    Consultați documentația CLI XSP pentru detalii. În esență, primul true securizează interfața cu TLS (certificatul de server este creat dacă este necesar) și al doilea true forțează interfața să solicite autentificarea certificatului de client (împreună sunt mTLS).

De exemplu:

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

În acest exemplu, mTLS (Client Auth Req = true) este activat pe 192.0.2.7 port 444. TLS este activat pe 192.0.2.7 port 443.

(Opțiune) Configurarea mTLS pentru anumite aplicații web

Este posibilă configurarea mTLS la nivel de interfață/port HTTP sau pe bază de aplicație web.

Modul în care activați mTLS pentru aplicația dvs. Dacă găzduiți mai multe aplicații care necesită mTLS, ar trebui să activați mTLS pe interfață. Dacă trebuie doar să securizați una dintre mai multe aplicații care utilizează aceeași interfață HTTP, puteți configura mTLS la nivel de aplicație.

La configurarea mTLS la nivel de aplicație, mTLS este necesar pentru aplicația respectivă, indiferent de configurația interfeței serverului HTTP.

  1. Conectați-vă la XSP a cărui interfață o configurați.

  2. Navigare la XSP_CLI/Interface/Http/SSLCommonSettings/ClientAuthentication/WebApps> și rulați get pentru a vedea ce aplicații se execută.

  3. Pentru a adăuga o aplicație și a solicita autentificarea clientului pentru aceasta (ceea ce înseamnă același lucru cu mTLS):

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

    Consultați documentația CLI XSP pentru detalii. Numele aplicațiilor sunt enumerate acolo. cel true în această comandă permite mTLS.

De exemplu:

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

Comanda exemplu adaugă aplicația AuthenticationService la 192.0.2.7:443 și îi solicită să solicite și să autentifice certificate de la client.

Verificați cu get:

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

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

Cerințe suplimentare de certificat pentru autentificarea TLS reciprocă împotriva AuthService

Webex interacționează cu Serviciul de autentificare printr-o conexiune autentificată TLS reciprocă. Aceasta înseamnă că Webex prezintă un certificat de client, iar XSP trebuie să îl valideze. Pentru a avea încredere în acest certificat, utilizați lanțul de certificate Webex CA pentru a crea o ancoră de încredere pe XSP (sau proxy). Lanțul de certificate este disponibil pentru descărcare prin Partner Hub:

  1. Accesați Setări > Apelare BroadWorks.

  2. Faceți clic pe linkul descărcare certificat.


De asemenea, puteți obține lanțul de certificate de la https://bwks-uap.webex.com/assets/public/CombinedCertChain.txt.

Cerințele exacte pentru implementarea acestui lanț de certificate Webex CA depind de modul în care sunt implementate XSP-urile cu care se confruntă publicul:

  • Printr-un proxy de punte TLS

  • Printr-un proxy pass-through TLS

  • Direct la XSP

Următoarea diagramă rezumă unde trebuie implementat lanțul de certificate Webex CA în aceste trei cazuri.

Cerințe reciproce de certificat TLS pentru proxy-ul TLS-bridge

  • Webex prezintă proxy-ului un certificat de client semnat Webex CA.

  • Lanțul de certificate Webex CA este implementat pe depozitul de încredere proxy, astfel încât proxy-ul are încredere în certificatul client.

  • Certificatul de server XSP semnat public este, de asemenea, încărcat în proxy.

  • Proxy-ul prezintă webex un certificat de server semnat public.

  • Webex are încredere în CA publice care a semnat certificatul de server proxy lui.

  • Proxy-ul prezintă XSP-urilor un certificat de client semnat intern.

    Acest certificat trebuie să aibă câmpul de extensie x509.v3 Utilizare extinsă cheie populată cu scopul BroadWorks OID 1.3.6.1.4.1.6431.1.1.8.2.1.3 și scopul TLS clientAuth. Exemplu.:

    X509v3 extensions:

    X509v3 Extended Key Usage:

    1.3.6.1.4.1.6431.1.1.8.2.1.3, TLS Web Client
                  Authentication 

    Când generați certificate client interne pentru proxy, rețineți că certificatele SAN nu sunt acceptate. Certificatele de server interne pentru XSP pot fi SAN.

  • XSP-urile au încredere în CA-ul intern.

  • XSP-urile prezintă un certificat de server semnat intern.

  • Proxy-ul are încredere în CA-ul intern.

Cerințe reciproce de certificat TLS pentru proxy-ul TLS-passthrough sau XSP în DMZ

  • Webex prezintă XSP-urilor un certificat de client semnat webex CA.

  • Lanțul de certificate Webex CA este implementat în depozitul de încredere XSP-urilor, astfel încât XSP-urile au încredere în certificatul de client.

  • Certificatul de server XSP semnat public este, de asemenea, încărcat în XSP-uri.

  • XSP-urile prezintă certificate de server semnate public către Webex.

  • Webex are încredere în CA publice care a semnat certificatele de server XSPs ".