Intégration avec un serveur de contrôle d’accès tiers

Cette fonctionnalité permet aux appareils Akuvox de transférer des identifiants d’accès (tels que des codes QR, des cartes ou des codes PIN) à un serveur tiers pour vérification, au lieu d’effectuer une authentification locale.

Cas d’usage typiques :

• Contrôle d’accès centralisé géré par une plateforme tierce.

• Logique de sécurité personnalisée implémentée sur des serveurs externes.

Comment cela fonctionne :

Modèles pris en charge

Cette fonctionnalité est prise en charge sur les modèles suivants :

Avant de commencer

Assurez-vous d’avoir :

• L’API HTTP fournie par le serveur tiers.

• ID de périphérique attribué par le système tiers.

• Méthode d’authentification prévue (code QR, carte, code PIN ou multi-facteurs).

Aperçu de la configuration

Deux modes d’intégration sont pris en charge :

Intégration générale  

• Utilisé uniquement pour l’authentification par code QR.

• L’appareil envoie une requête HTTP prédéfinie contenant des données de code QR.

Intégration personnalisée  

• Utilisé pour plusieurs méthodes d’authentification.

• Prend en charge le code QR, la carte, le code PIN et l’authentification multi-facteurs.

• Permet une mise en forme flexible des données pour le traitement côté serveur.

Étapes de configuration

Prenons A08 comme exemple.

1. Utilisez l’adresse IP de l’appareil pour vous connecter à son interface web. Le nom d’utilisateur initial et le mot de passe sont admin.

2. Va dans le contrôle d’accès > le relais > intégration tierce.

3. Sélectionnez le type d’intégration.

• Général : Transmettez l’URL HTTP liée par code QR dans la méthode d’Akuvox.

• Personnalisez : Transmettez les données d’accès aux identifiants de manière personnalisée.

Option A : Intégration générale (code QR uniquement)

Quand utiliser :

• Seule l’authentification par code QR est requise.

• Le serveur vérifie les codes QR via des requêtes HTTP.

1. Voici la commande HTTP fournie par le fournisseur de services tiers.

   Exemple de format :

   http://192.168.31.123:8090/api/visitor/scan?codeKey={QRCode}&deviceId={DeviceID}

2. Saisissez l’identifiant de l’appareil fourni par le serveur tiers.

3. Soumettez le cadre.

Format de réponse serveur

Après avoir reçu la demande, le serveur tiers doit renvoyer une réponse JSON valide indiquant si l’accès est accordé.

Le dispositif détermine le résultat en fonction de champs spécifiques dans la réponse.

Paramètre de réussite supporté :

• « est valide » : vrai

• « est valide » : 1

• « validation_result » : « 1 »

Paramètre défaillant pris en charge :

• « est invalide » : faux

• « est valide » : 0

• « validation_result » : « 0 »

Délai d’attente de réponse

L’appareil attend une réponse du serveur tiers dans un délai limité.

• Temps mort : 3 secondes

Si aucune réponse valide n’est reçue dans ce délai :

• La demande sera considérée comme échouée.

• L’accès sera automatiquement refusé.

Résultat

• Lorsqu’un code QR est scanné :

  • {QRCode} est remplacé par le contenu QR réel.

  • {DeviceID} identifie l’appareil.

• Le serveur vérifie la demande.

• L’appareil ouvre la porte si la vérification réussit.

Option B : Intégration personnalisée

Quand utiliser :

• Plusieurs méthodes d’authentification sont nécessaires.

• Une logique de vérification personnalisée est implémentée sur le serveur.

Références prises en charge :

• Code QR

• Carte RF

• PIN

• Authentification multi-facteurs

Avant de configurer l’intégration, spécifiez quel mode d’authentification est utilisé par l’appareil.

Sélectionnez le mode d’authentification sur l’interface de contrôle d’accès > relais > mode d’authentification d’accès .

Scénario 1 : N’importe quel mode méthode

Dans ce mode, toute accréditation sélectionnée peut déclencher une vérification.

1. Sélectionnez la(s) méthode(s) d’accès à vérifier par le serveur tiers.

2. Voici la commande HTTP fournie par le fournisseur de services tiers.

   Exemple de format :

   http://192.168.31.123:8090/api/visitor/scan?codeKey={QRCode}/{Card}/{Pin}&deviceId={DeviceID}.

3. Saisissez l’identifiant de l’appareil fourni par le serveur tiers.

4. Soumettez le cadre.

Conseil

Certains modèles spécifiques (X916, S535, R29, A05V2, E18 et E16V2) prennent en charge la fonction Prompt on LCD .

• Sélectionnez par défaut pour adopter l’invite d’ouverture de porte du téléphone Akuvox.

• Sélectionnez Retour de valeur pour utiliser la valeur de retour du serveur tiers comme invite.

Format de réponse serveur

Après avoir reçu la demande, le serveur tiers doit retourner une réponse valide indiquant si l’accès est accordé.

Le dispositif détermine le résultat en fonction de champs spécifiques dans la réponse.

Paramètre de réussite supporté :

• « est valide » : vrai

• « est valide » : 1

• « validation_result » : « 1 »

Paramètre défaillant pris en charge :

• « est invalide » : faux

• « est valide » : 0

• « validation_result » : « 0 »

Délai d’attente de réponse

L’appareil attend une réponse du serveur tiers dans un délai limité.

• Temps mort : 3 secondes

Si aucune réponse valide n’est reçue dans ce délai :

• La demande sera considérée comme échouée.

• L’accès sera automatiquement refusé.

Résultat

• L’appareil envoie l’identifiant utilisé (QR, carte ou code PIN).

• La variable correspondante est remplacée dans l’URL.

• Le serveur vérifie l’identifiant et renvoie le résultat.

Scénario 2 : Mode d’authentification à deux facteurs

Ce mode nécessite deux identifiants en séquence. Les combinaisons prises en charge sont Carte RF + PIN et PIN + Carte RF.

Flux de travail :

L’utilisateur complète la première étape ➡ d’authentification L’appareil envoie les premières données d’identifiants au serveur ➡ L’utilisateur complète la deuxième étape ➡ d’authentification L’appareil envoie les secondes données d’identifiants au serveur.

1. Sélectionnez le mode de vérification à distance multi-facteurs .

• Si la méthode d’accès n’est pas correspondante, l’utilisateur est invité à utiliser la bonne méthode.

• Si elles sont correspondantes, les identifiants collectés sont envoyés au serveur pour vérification.

2. Voici la commande HTTP fournie par le fournisseur de services tiers.

   Exemple de format :

   http://192.168.31.123:8090/api/visitor/scan?codeKey={Token}/{Type}&deviceId={DeviceID}

3. Saisissez l’identifiant de l’appareil fourni par le serveur tiers.

4. Soumettez le cadre.

Conseil

Certains modèles spécifiques (X916, S535, R29, A05V2, E18 et E16V2) prennent en charge la fonction Prompt on LCD .

• Sélectionnez par défaut pour adopter l’invite d’ouverture de porte du téléphone Akuvox.

• Sélectionnez Retour de valeur pour utiliser la valeur de retour du serveur tiers comme invite.

Format de réponse serveur

Après avoir reçu la demande, le serveur tiers doit renvoyer une réponse JSON valide indiquant si l’accès est accordé.

Le dispositif détermine le résultat en fonction de champs spécifiques dans la réponse.

Paramètre de réussite supporté :

• « est valide » : vrai

• « est valide » : 1

• « validation_result » : « 1 »

Paramètre défaillant pris en charge :

• « est invalide » : faux

• « est valide » : 0

• « validation_result » : « 0 »

Délai d’attente de réponse

L’appareil attend une réponse du serveur tiers dans un délai limité.

• Temps mort : 3 secondes

Si aucune réponse valide n’est reçue dans ce délai :

• La demande sera considérée comme échouée

• L’accès sera automatiquement refusé

Résultat

• {Token} représente la qualification recueillie à chaque étape.

• {Type} indique la séquence d’authentification :

  • 1 = Carte RF + PIN

  • 2 = PIN + Carte RF

• Le serveur vérifie les deux identifiants avant d’accorder l’accès.

Variable Description

Différences de capacités de modèle

Capacités d’authentification

Différents modèles prennent en charge différentes méthodes d’authentification pour l’intégration avec des serveurs tiers.

Variables prises en compte par modèle

Différents modèles prennent en charge différentes variables lors de l’envoi de données vers le serveur.

Note

• Les formats variables ne sont PAS interchangeables entre les modèles.

• Seules les variables prises en charge par le modèle de périphérique peuvent être utilisées dans la commande HTTP.

• L’utilisation de variables non prises en charge peut entraîner des requêtes échouées.