Envoyer une notification quand un objet, un terminal ou une personne entre dans un espace ou sort d’un périmètre précis, ou encore permettre/bloquer l’accès au réseau selon la zone de connexion : des besoins auxquels nous pouvons répondre avec les technologies Wi-Fi et de contrôle d’accès, et que nous allons détailler dans cet article.
Le terme « geofencing » est utilisé parfois pour différents types de besoins liés à la géolocalisation des terminaux/utilisateurs et aux actions que l’on peut déclencher par rapport à cette géolocalisation.
La solution Cisco Connected Mobile Experiences (CMX) permet de s’appuyer sur un catalogue d’API, pour aller chercher les données de géolocalisation des terminaux Wi-Fi (y compris les tags Wi-Fi), ou alors pour envoyer dynamiquement ces données suite à la vérification de certaines conditions. Cette dernière option est supportée à travers un système de notifications, appelées aussi « Northbound Notifications », grâce auxquelles on peut paramétrer différentes conditions pour déclencher des messages XML/JSON vers des ressources externes. Par exemple, on pourrait envoyer une notification dès qu’un terminal associé au Wi-Fi entre dans une zone précise d’un étage (la zone « Lobby » du 4ème étage dans l’image ci-dessous) :
Ces notifications API peuvent être ensuite traitées par des outils externes pour l’analytique, la corrélation d’événements, la génération d’autres alertes, etc.
Un autre cas d’usage est représenté souvent par les tags Wi-Fi montés sur des équipements métiers spécifiques (outillage, pièces détachées, robots mobiles, chariots, etc.) et qui permettent justement d’avoir une radio Wi-Fi sur des objets normalement pas équipés pour cela. Cette radio n’a toutefois pas l’objectif de connecter ces objets au réseau, mais plutôt d’envoyer des signaux Wi-Fi périodiques (parfois même avec des informations additionnelles comme le niveau de batterie, la température, l’appui sur un bouton d’urgence, etc.) pour en permettre la géolocalisation. Les notifications de CMX relatives aux tags Wi-Fi, parfois appelés « RFID Tags », peuvent également se baser sur des données plus avancées et incluses par les tags dans les options CCX (Cisco Compatible eXtensions) des trames Wi-Fi :
En plus que déclencher des notifications/alertes par rapport aux coordonnées de géolocalisation, dans certains déploiements on pourrait implémenter la vérification de la zone de géolocalisation avant d’autoriser un terminal sur le réseau Wi-Fi. Une telle option est disponible à travers Cisco Identity Services Engine (ISE) et le support de son interconnexion avec les API de Cisco MSE (Mobility Services Engine). Grâce à cette intégration, ISE peut récupérer la zone dé géolocalisation d’un terminal et l’utiliser dans ses politiques d’autorisation (en plus que des conditions plus « classiques », bien évidemment, comme les attributs des certificats, les groupes AD, le profiling, le contrôle de conformité, etc.).
Cependant, il faut garder à l’esprit que le Wi-Fi en tant que technologie de géolocalisation supporte en moyenne des taux de précision de 5-10 mètres, en descendant à 1-3 mètres dans les meilleurs des cas. Vue la marge d’erreur, et parfois le fait qu’un déploiement Wi-Fi supportant la géolocalisation requiert des études radio et des équipements additionnels par rapport à une installation pour les services data ou voix uniquement, on peut dans la plupart des cas répondre à ce besoin spécifique avec des options déjà disponibles directement dans les contrôleurs Wi-Fi Cisco.
Une technique de contrôle d’accès basée sur la localisation d’un terminal consiste par exemple à lier cette localisation à la borne Wi-Fi ou au groupe des bornes Wi-Fi depuis lesquelles on peut se connecter. Le contrôleur Wi-Fi supporte dans les requêtes RADIUS l’attribut standard [30] Called-Station-Id, qui peut être paramétré pour inclure des informations comme le nom de l’AP, ou le nom de l’AP Group, le nom du FlexConnect Group, ou encore le nom de la « location » d’un AP (un attribut qu’on peut configurer pour chaque AP ou pour plusieurs AP en parallèle avec des templates) :
Dans les politiques d’autorisation du serveur RADIUS on peut ensuite paramétrer des conditions se basant sur la valeur de l’attribut RADIUS [30] Called-Station-Id pour autoriser un terminal/utilisateur sur le réseau (en plus que la vérification de son certificat, groupe AD, profil, état de conformité, etc.), ou encore pour le rediriger vers un portail captif personnalisé par rapport à sa localisation justement. Voici un exemple rapide de configuration d’un WLC Cisco et d’une politique dans ISE utilisant cette technique :
Cet exemple peut être appliqué à d’autres serveurs RADIUS aussi, en le réadaptant selon leurs options de configuration supportées.
N’hésitez pas à laisser vos commentaires dans la section dédiée du blog pour toute éventuelle question sur ces sujets !
Authors