Publication Web de CUCM

décembre 21, 2010  |   Blog   |     |   Commentaires fermés sur Publication Web de CUCM

Lors d’une récente mission d’Assistance technique à la maitrise d’ouvrage sur un déploiement de ToIP Cisco CUCM 8.0.2, nous avons été confrontés à un certain nombre de problèmes.

L’un d’eux résidait dans la façon dont est publiée l’interface Web/Webservice du CUCM.

Pour rappel, celle-ci sert notamment à :

  • la personalisation du téléphone (numéros abrégés = speed dial, répertoire personnel ,etc..)
  • lors des appels réalisés par le widget Cisco « click to call » (que j’appellerais plutot « higlight to call »)

En effet, plusieurs serveurs remplissent ces rôles (publisher & subscriber) : dans le cas présent pour 1200 utilisateurs , pas moins de 4 serveurs.

Ces 4 serveurs possèdent chacun leur propre certificat (en général basé sur leur adresse IP).

D’où les problématiques suivantes :

  • pas de mécanisme de load-balacing / répartition de charge prévu nativement
  • chaque serveur présente un certificat doté d’un DN différent ce qui provoque des alertes au niveau du navigateur ou du widget, si par exemple on utilise un load-balancer de niveau 4 ou bien du round-robin DNS.

De plus l’URL par défaut (« / ») pointe sur « /ccmadmin », l’interface d’administration du CUCM !! Il faut donc que l’utilisateur renseigne parfaitement l’URL « http://cucm_serverIP/ccmuser » pour se voir présenter la page de connexion.

La solution consiste bien sûr à « reverse proxyer » ces serveurs.

Nous l’avons réalisé avec Apache en présentant un virtual host nommé « myphone » (facile à retenir pour les utilisateurs !) qui consulte en partage de charge les différents serveurs CUCM en backend (modules mod_proxy et mod_balancer).

Le VirtualHost principal écoute en SSL sur les ports 443 et 8443 (utilisé par le webservice du click-to-call).

NB : Supposons que les CUCM ont pour adresse IP 10.1.1.X (avec X variant de 1 à 4):

Listen 443
Listen 8443
LoadModule ssl_module modules/mod_ssl.so

<PROXY pool_cucm balancer:>
BalancerMember https://10.1.1.1 route=1
BalancerMember https://10.1.1.2 route=2
BalancerMember https://10.1.1.3 route=3
BalancerMember https://10.1.1.4 route=4
ProxySet stickysession=ROUTEID nofailover=off
</PROXY>

<VIRTUALHOST *:8443 *:443 >
ServerName myphone
SSLEngine On
SSLCertificateFile ssl/myphone.crt
SSLCertificateKeyFile ssl/myphone.key
SSLProxyEngine On

ProxyRequests off
Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED

ProxyPass / balancer://pool_cucm/
ProxyPassReverse / balancer://pool_cucm/

ErrorLog /var/log/www/myphone/apache_error_ssl_log
CustomLog /var/log/www/myphone/apache_access_ssl_log combined

</VIRTUALHOST>

Vous noterez l’insertion du cookie ROUTEID, qui est le seul moyen que j’ai trouvé pour assurer une persistence pour les clients ( mod_proxy_balancer ne saura pas analyser les cookies natifs de l’appli CUCM JSESSIONID et JESSIONIDSSO ).

 

Un second VirtualHost sur le port 80 ne sert qu’à la redirection initiale vers le HTTPS et l’URL « /ccmuser/showHome.do ».

 

<VIRTUALHOST *:80>
ServerName myphone
ServerAlias myphone
DocumentRoot /var/www/html
DirectoryIndex index.php

ErrorLog /var/log/www/myphone/apache_error_log
CustomLog /var/log/www/myphone/apache_access_log combined
</VIRTUALHOST >

 

Sauf qu’avec la version 8.0.2 (au moins), l’application Web est mal écrite : l’adresse IP (ou le nom) du CUCM est présente dans le javascript généré pour la page de login (« /ccmuser/showHome.do ») et celle de logout (« /ccmuser/securitycheck ») !!

Il faut donc non seulement modifier les headers (ce que fait mod_proxy) mais également les pages.

Ceci peut être pris en compte par un module spécifique nommé mod_proxy_html.

Malheureusement ce module (où le JS généré est buggé) tronque le contenu de certaines pages, ce qui fait qu’il faut vraiment le limiter aux URLs pré-citées pour éviter ces effets de bord.

Voici la configuration Apache qui permet ceci :

<LOCATION (showHome.do|j_security_check)$ ~>
ProxyHTMLMeta On
ProxyHTMLLogVerbose On
ProxyHTMLEnable On
ProxyHTMLURLMap https://10.1.1../ https://myphone/ R
ProxyHTMLURLMap https://10.1.1.1..:8443/ https://myphone/ R
</LOCATION>

Le double point (..) après 10.1.1.1 n’est pas une typo : le dernier point signifie en regexp, que n’importe quel caractère est possible (dans notre cas, 1 à 4)

 
Ce billet illustre bien qu’il faut considérer les systèmes de téléphonie sur IP comme des applications multi-tiers (cf écosystème, attendant-console / poste standard, UCCX ou UCCE, filtrage patron/secrétaire, etc..) et prévoir les infrastructures qui accompagnent généralement ces applications (PKI, Reverse-Proxy, Partage de charge, chiffrement SSL, sauvegarde , stratégies de mot de passe, etc..)

Les commentaires sont fermés.