Annexe

Configurer le service d’authentification XSP (avec mTLS)

Terminez les procédures dans cet annexe pour configurer le service d’authentification sur BroadWorks pour utiliser l’authentification mTLS. Dans les cas où la validation du jeton CI (avec TLS) n’est pas prise en charge, l’authentification mTLS est obligatoire, incluant les instances suivantes :

  • Si vous avez la R21SP1 en cours

  • Si vous avez le même serveur XSP et que plusieurs organisations Webex sont en cours d’exécution


Si vous avez le même serveur R22 ou supérieur et que plusieurs organisations Webex ne fonctionnent pas sur le même serveur XSP, la validation du jeton CI (avec TLS) est recommandée pour le service d'1ère auth. Pour des détails, voir Configurer le service d’authentification (avec validation du jeton CI) dans le chapitre Déployer Webex pour BroadWorks.

Installer le service d’authentification

Sur BroadWorks 21SP1, le service d’authentification est une application nonmanée. Installez-le en suivant les étapes suivantes :

  1. Téléchargez authenticationService_1.0.war (ressource d’application web) à partir de Xchange (https://xchange.broadsoft.com/node/499012).

    Sur chaque XSP utilisé avec Webex, faites les choses suivantes :

  2. Copiez le fichier .war dans un emplacement temporaire sur le XSP, tel que /tmp/

  3. Installez l’application du service d’authentification avec le contexte et la commande CLI suivants :

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

Configurer le service d’authentification

Les jetons longs et hébergés par BroadWorks sont générés et validés par le service d’authentification hébergé sur vos XSP.

Exigences

  • Les serveurs XSP hébergeant le service d’authentification doivent avoir une interface mTLS configurée.

  • Les XSP doivent partager les mêmes clés pour chiffrer/déchiffrer les jetons BroadWorks longs et chiffrements. Copier ces clés vers chaque XSP est un processus manuel.

  • Les XSP doivent être synchronisés avec le NTP.

Aperçu de la configuration

La configuration essentielle sur vos XSP inclut :

  • Déployer le service d’authentification.

  • Configurez la durée du jeton sur au moins 60 jours (laissez l’émetteur en tant que BroadWorks).

  • Générer et partager les clés RSA entre les XSP.

  • Fournissez l’URL du service auth vers le conteneur Web.

Déployer le service d’authentification sur XSP

Sur chaque XSP utilisé avec Webex :

  1. Activer l’application de service d’authentification sur le chemin /authService(vous devez utiliser ce chemin) :

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

    (où <version> Est 1.0 pour l’application nonmanée sur 21SP1).

  2. Déployer l’application :

    XSP_CLI/Maintenance/ManagedObjects> deploy application /authService

Configurer la durée du jeton

  1. Vérifiez la configuration du jeton existant (heures) :

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

  2. Définissez la durée sur 60 jours (le maximum est 180 jours) :

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

Générer et partager les clés RSA

  • Vous devez utiliser les mêmes paires de clés publiques/privées pour le chiffrement/déchiffrage du jeton dans toutes les instances du service d’authentification.

  • La paire de clés est générée par le service d’authentification lorsqu’il est nécessaire d’émettre un jeton pour la première fois.

En raison de ces deux facteurs vous devez générer des clés sur un XSP puis les copier vers tous les autres XSP.


Si vous cyclez des touches ou si vous changez la longueur de la clé, vous devez répéter la configuration suivante et redémarrer tous les XSP.

  1. Sélectionnez un XSP à utiliser pour générer un pair clé.

  2. Utilisez un client pour demander un jeton chiffré à partir de ce XSP, en demandant l’URL suivante à partir du navigateur du client :

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

    (Ceci génère un pair de clé privée/publique sur le XSP, s’il n’y en avait pas déjà un)

  3. (21SP1 uniquement) Vérifiez l’emplacement de la clé configurable en utilisant la commande suivante :

    XSP_CLI/Applications/authenticationService_1.0/KeyManagement> get

  4. (21SP1 uniquement) Prenez note du renvoyé fileLocation AUTOOC.

  5. (21SP1 uniquement) Copier tout fileLocation répertoire, qui contient public et private sous-directionnels, à tous les autres XSP.

Fournissez l’URL du service auth vers le conteneur Web

Le conteneur Web du XSP a besoin de l’URL authService pour pouvoir valider les jetons.

Sur chacun des XSP :

  1. Ajouter l’URL du service d’authentification en tant que service d’authentification externe pour l’utilitaire BroadWorks Communications :

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

  2. Ajoutez l’URL du service d’authentification au conteneur :

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

    Ceci permet à Webex d’utiliser le service d’authentification pour valider les jetons présentés comme identifiants.

  3. Vérifiez le paramètre avec get.

  4. Redémarrez le XSP.

Configurer la confiance pour le service d’authentification (avec mTLS)

Configurer la confiance (R21 SP1)
  1. Connectez-vous au Hub partenaire.

  2. Allez dans Paramètres > BroadWorks Calling et cliquez sur Télécharger le certificat de l’AC Webex pour obtenir CombinedCertChain.txt sur votre ordinateur local.


    Ce fichier contient deux certificats. Vous devez diviser le fichier avant de le télécharger vers le site XSP.
  3. Divisez la chaîne de certificats en deux certificats :

    1. Ouvrir combinedcertchain.txt dans un éditeur de texte.

    2. Sélectionner et couper le premier bloc de texte, incluant les lignes -----BEGIN CERTIFICATE----- et -----END CERTIFICATE----- et collez le bloc de texte dans un nouveau fichier.

    3. Enregistrer le nouveau fichier sous broadcloudroot.txt.

    4. Enregistrez le fichier d’origine sous broadcloudissuing.txt.

      Le fichier d’origine ne doit à présent avoir qu’un seul bloc de texte, entouré des lignes -----BEGIN CERTIFICATE----- et -----END CERTIFICATE-----.

  4. Copiez les deux fichiers texte dans un emplacement temporaire sur le XSP que vous êtes en mesure de sécuriser, par exemple /tmp/broadcloudroot.txt et /tmp/broadcloudissuing.txt.

  5. Connectez-vous au XSP et accédez à /XSP_CLI/Interface/Http/ClientAuthentication>

  6. Exécutez le fichier get commande et lisez le chainDepth AUTOOC.

    (chainDepth est 1 par défaut, ce qui est trop bas pour la chaine Webex qui a deux certificats)

  7. Si la chaîneDepth n’est pas déjà supérieure à 2, exécutez set chainDepth 2.

  8. (Facultatif) Courir help updateTrust pour voir les paramètres et le format de la commande.

  9. Téléchargez les fichiers du certificat vers des nouvelles ancres d’autorisation :

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

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


    webexclientroot et webexclientissuing sont des alias pour les chevilles de confiance ; vous pouvez utiliser le vôtre.
  10. Confirmez que les deux certificats sont téléchargés :

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

Configurer la confiance (R22 et plus tard)

  1. Connectez-vous à Control Hub avec votre compte administrateur partenaire.

  2. Allez dans Paramètres > BroadWorks Calling et cliquez sur Télécharger le certificat de l’AC Webex pour obtenir CombinedCertChain.txt sur votre ordinateur local.


    Ce fichier contient deux certificats. Vous devez diviser le fichier avant de le télécharger vers le site XSP.
  3. Divisez la chaîne de certificats en deux certificats :

    1. Ouvrir combinedcertchain.txt dans un éditeur de texte.

    2. Sélectionner et couper le premier bloc de texte, incluant les lignes -----BEGIN CERTIFICATE----- et -----END CERTIFICATE----- et collez le bloc de texte dans un nouveau fichier.

    3. Enregistrer le nouveau fichier sous broadcloudroot.txt.

    4. Enregistrez le fichier d’origine sous broadcloudissuing.txt.

      Le fichier d’origine ne doit à présent avoir qu’un seul bloc de texte, entouré des lignes -----BEGIN CERTIFICATE----- et -----END CERTIFICATE-----.

  4. Copiez les deux fichiers texte dans un emplacement temporaire sur le XSP que vous êtes en mesure de sécuriser, par exemple /tmp/broadcloudroot.txt et /tmp/broadcloudissuing.txt.

  5. (Facultatif) Courir help UpdateTrust pour voir les paramètres et le format de la commande.

  6. Téléchargez les fichiers du certificat vers des nouvelles ancres d’autorisation :

    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 et webexclientissuing sont des alias pour les chevilles de confiance ; vous pouvez utiliser le vôtre.
  7. Confirmez que les chevilles sont mises à jour :

    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]

(Option) Configurer mTLS au niveau de l’interface HTTP/port

Il est possible de configurer mTLS au niveau de l’interface/du port HTTP ou sur une base d’application par web.

La façon dont vous activez mTLS pour votre application dépend des applications que vous organisez sur le XSP. Si vous organisez plusieurs applications qui nécessitent mTLS, vous devez activer mTLS sur l’interface. Si vous avez uniquement besoin de sécuriser l’une des applications qui utilisent la même interface HTTP, vous pouvez configurer mTLS au niveau de l’application.

Lors de la configuration de mTLS à l’interface HTTP/niveau du port, mTLS est requis pour toutes les applications web hébergées accédées via cette interface/port.

  1. Connectez-vous au XSP dont vous êtes en train de configurer l’interface.

  2. Naviguer vers XSP_CLI/Interface/Http/HttpServer> et exécutez le get pour voir les interfaces.

  3. Pour ajouter une interface et exiger l’authentification du client ici (ce qui signifie la même chose que mTLS) :

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

    Voir la documentation XSP CLI pour plus de détails. Essentiellement, la première true sécurisation de l’interface avec TLS (le certificat du serveur est créé si nécessaire) et le second true force l’interface à exiger l’authentification du certificat du client (ensemble, ils sont mTLS).

Par exemple :

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

Dans cet exemple, mTLS (Client Auth Req = true) est activé 192.0.2.7 port 444. TLS est activé sur 192.0.2.7 port 443.

(Option) Configurer mTLS pour des applications Web spécifiques

Il est possible de configurer mTLS au niveau de l’interface/du port HTTP ou sur une base d’application par web.

La façon dont vous activez mTLS pour votre application dépend des applications que vous organisez sur le XSP. Si vous organisez plusieurs applications qui nécessitent mTLS, vous devez activer mTLS sur l’interface. Si vous avez uniquement besoin de sécuriser l’une des applications qui utilisent la même interface HTTP, vous pouvez configurer mTLS au niveau de l’application.

Lors de la configuration de mTLS au niveau de l’application, mTLS est requis pour cette application quelle que soit la configuration de l’interface du serveur HTTP.

  1. Connectez-vous au XSP dont vous êtes en train de configurer l’interface.

  2. Naviguer vers XSP_CLI/Interface/Http/SSLCommonSettings/ClientAuthentication/WebApps> et exécutez le get pour voir quelles applications sont en cours d’exécution.

  3. Pour ajouter une application et exiger une authentification du client pour cela (ce qui signifie la même chose que mTLS) :

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

    Voir la documentation XSP CLI pour plus de détails. Les noms des applications y sont reprises. Le true dans cette commande active mTLS.

Par exemple :

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

L’exemple de commande ajoute l’application Service d’authentification à la commande 192.0.2.7:443 et nécessite qu’elle demande et authentifier les certificats du client.

Vérifier avec get:

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

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

Exigences de certificats supplémentaires pour l’authentification TLS mutuelle contre AuthService

Webex interagit avec le service d’authentification sur authentification TLS mutuelle connexion authentifiée. Ceci signifie que Webex présente un certificat client et que le XSP doit le valider. Pour faire confiance à ce certificat, utilisez la chaine de certificats de l’AC Webex pour créer une ancre d’autorisation sur le serveur XSP (ou proxy). La chaine de certificats est disponible au téléchargement via partner hub :

  1. Allez dans Paramètres > BroadWorks Calling.

  2. Cliquez sur le lien télécharger le certificat.


Vous pouvez également obtenir la chaine de certificats à partir https://bwks-uap.webex.com/assets/public/CombinedCertChain.txtde .

Les exigences exactes pour le déploiement de cette chaine de certificats d’ac Webex dépend de la manière dont vos XSP publics sont déployés :

  • Via un proxy de transition TLS

  • Via un proxy d’accès TLS

  • Directement vers le XSP

Le diagramme suivant résume l’endroit où la chaine de certificats de l’AC Webex doit être déployée dans ces trois cas.

Exigences du certificat TLS mutuel pour le proxy TLS-bridge

  • Webex présente un certificat client Signé par une AC Webex au proxy.

  • La chaine de certificats de l’AC Webex est déployée sur le magasin de confiance des proxys, donc le proxy fait confiance au certificat du client.

  • Le certificat du serveur XSP signé publiquement est également chargé dans le proxy.

  • Le proxy présente un certificat de serveur signé publiquement à Webex.

  • Webex fait confiance à l’AC publique qui a signé le certificat du serveur du proxy.

  • Le proxy présente un certificat client signé en interne aux XPS.

    Ce certificat doit avoir le champ d’extension x509.v3 Utilisation étendue de la clé rempli avec l’OID BroadWorks 1.3.6.1.4.1.6431.1.1.8.2.1.3 et l’objectif unique du client TLS. P. ex.:

    X509v3 extensions:

    X509v3 Extended Key Usage:

    1.3.6.1.4.1.6431.1.1.8.2.1.3, TLS Web Client
                  Authentication 

    Lors de la génération des certificats du client interne pour le proxy, notez que les certificats SAN ne sont pas pris en charge. Les certificats du serveur interne pour le XSP peuvent être SAN.

  • Les XSP font confiance à l’AC interne.

  • Les XSP présentent un certificat de serveur signé en interne.

  • Le proxy fait confiance à l’AC interne.

Exigences du certificat TLS mutuel pour le Proxy d’accès TLS ou XSP dans le DMZ

  • Webex présente un certificat de client Webex CA signé aux XSP.

  • La chaine de certificats des AC Webex est déployée sur le magasin de confiance des XSP, donc les XSP font confiance au certificat du client.

  • Le certificat du serveur XSP signé publiquement est également chargé dans les XSP.

  • Les XSP présentent des certificats de serveur signés publiquement à Webex.

  • Webex fait confiance à l’AC publique qui a signé les certificats du serveur XSP.