HomeUse CasesConceptsConfig GuidesDeveloper GuidesAPI Reference
Content

Dépannage de l'accès adaptatif

Suggest Edits

👍

Vérifier l'état du système

Avant de commencer le dépannage, il est recommandé de vérifier l'état actuel du système pour détecter les interruptions de service connues qui pourraient avoir un impact sur la collecte, la détection ou l'évaluation de la politique d'accès adaptatif.

Introduction

Si vous n'obtenez pas le comportement attendu d'une application web native configurée pour Adaptive Access, il vous faut un moyen de déterminer où se situe le problème. L'examen des événements et des rapports de votre locataire IBM Security Verify peut vous mettre sur la bonne voie.

Vous pouvez passer à la section appropriée de ce guide si vous pouvez identifier le problème :

Aucune entrée d'événement ou de rapport

Lorsqu'il n'y a pas d'événement ou d'entrée de rapport pour une tentative d'authentification connue dans l'application Web native, cela indique soit :

1344

Rapport d'accès adaptatif sans données d'événement

Aucune politique d'accès adaptatif

Dans une politique d'accès adaptatif, les règles de post-authentification invoquent une évaluation.

Vérifiez quelle politique d'accès est attachée à votre application. Intégrer une application native :

1344

Activer la politique d'accès adaptatif pour l'application

Assurez-vous que cette politique d'accès a la case Accès adaptatif activée :

1344

Activer la case à cocher Accès adaptatif dans la politique

🚧

Je ne vois pas l'accès adaptatif dans ma politique d'accès ?

Si vous ne voyez pas l'accès adaptatif dans votre politique d'accès, assurez-vous que la politique est une politique d'application web native. Si vous ne voyez pas l'option pour la politique d'application web native dans l'éditeur de politique, vérifiez que votre locataire est activé pour l'Accès Adaptatif (en vérifiant les abonnements).

La politique d'accès n'est pas appliquée pour le type d'octroi

Assurez-vous que la politique d'accès est appliquée pour JWT Bearer dans la section Appliquer la politique d'accès aux types d'octroi API de la définition d'application. Si vous ne voyez pas un événement attendu lors d'un flux de type d'octroi différent (par exemple, flux de rafraîchissement), assurez-vous que ce type d'octroi est également sélectionné.

Voir exemple pour le type d'octroi de rafraîchissement ici.

Données insuffisantes

Lors de l'Utilisation du Proxy SDK pour authentifier un utilisateur, la fonction adaptive.assessPolicy(context) nécessite un context similaire à :

var context = {
    sessionId : req.body.sessionId, // L'ID de session généré posté depuis le navigateur
    userAgent : req.headers['user-agent'], // L'agent utilisateur collecté depuis les en-têtes
    ipAddress : req.ip // L'adresse source de la connexion IP.
};

Assurez-vous d'avoir :

  1. invoqué le getSessionId() depuis le Browser SDK.
    Référez-vous à Assurer que la collecte se termine pour les détails sur comment invoquer getSessionId() correctement.
  2. géré l'"error":"adaptive_more_info_required" indiquant qu'il y avait des données insuffisantes ou incorrectes fournies dans le contexte.
    Référez-vous à Effectuer une recollecte pour gérer l'erreur du Proxy SDK avec l'extrait fourni.

Impossible d'appliquer la politique d'accès ou IP de transfert invalide spécifiée dans la demande.

Lors de l'exécution d'une authentification utilisateur via le Proxy SDK, l'ipAddress définie dans l'objet context doit être une adresse IP routable sur Internet.

Les adresses IP invalides telles que les adresses de bouclage (:::1, 127.0.0.*), non-routables, et les adresses IP internes (192.168.0.*) entraînent que l'adresse IP collectée du navigateur des utilisateurs et l'adresse IP qui est rapportée du Proxy SDK ne correspondent pas. Cette non-correspondance fait que le flux policyAuth ne s'exécute pas.

Typiquement, lorsque le Proxy SDK est déployé comme application conteneurisée dans des environnements de non-production, la valeur req.ip est une adresse de bouclage entre l'application activée pour l'Adaptatif et les conteneurs Proxy. Lorsque cette valeur est transmise dans le flux, une erreur se produit en raison d'une adresse IP de transfert invalide.

var context = {
    sessionId : req.body.sessionId,
    userAgent : req.headers['user-agent'],
    ipAddress : req.ip // Cette valeur peut contenir une valeur invalide comme une adresse de bouclage.
};

Pour corriger ce problème, assurez-vous que l'adresse IP fournie peut être atteinte via Internet et ne représente pas une adresse de bouclage. Utilisez l'adresse IP du navigateur des utilisateurs explicitement, plutôt que de la prendre de la demande.

var context = {
    sessionId : req.body.sessionId,
    userAgent : req.headers['user-agent'],
    ipAddress : "<Adresse IP du navigateur de l'utilisateur>" // IP mise à jour pour éviter des valeurs inattendues
};

Lorsque l'authentification est effectuée, ce changement assure que le champ ipAddress correspond à ce qui est collecté de la collecte du navigateur de l'utilisateur. Il assure également que l'adresse IP réelle du navigateur des utilisateurs est utilisée. Cette correction n'est applicable que lorsque l'application s'exécute localement. Parce que vous vous connectez à l'application sur votre propre appareil, l'adresse IP extraite n'est pas l'IP externe du serveur, mais l'IP du conteneur local.

❗️

Mettre à jour ipAddress avec une valeur fixe dans les environnements locaux, de non-production uniquement.

Mettre à jour ipAddress avec une valeur fixe uniquement dans les environnements de non-production où les conteneurs et le navigateur de l'utilisateur s'exécutent localement.

Dans un environnement de production, l'application activée pour l'Adaptatif doit affirmer l'adresse IP réelle du navigateur de l'utilisateur au Proxy SDK. Elle doit correspondre à la valeur de l'adresse IP qui est collectée du navigateur de l'utilisateur.

La collecte n'a pas commencé

Lorsque le Browser SDK est initialisé sur la page de connexion, comme décrit dans Assurer que la collecte se termine, si la collecte ne démarre pas, aucun ID de session ne sera fourni et l'appel à getSessionId() ne retournera pas la valeur correcte.

Utilisez les Outils de développement dans votre navigateur pour vérifier que la collecte et la détection ont commencé.
Vous devriez voir des demandes dans l'onglet Network qui incluent une demande à l'hôte cloudfront spécifié dans l'extrait web qui a été généré lors de l'intégration de l'application native
Par exemple https://d1anfu45urknyg.cloudfront.net/511843/aloads.js?dt=login&r=0.3289762412868322.
Vous devriez voir des chargeurs JavaScript supplémentaires demandés, qui peuvent inclure

  • bits.js
  • main.js
  • tags.js

Ces chargeurs devraient retourner un code de réponse 200 avec un corps de réponse non vide.

De plus, vous devriez voir plusieurs demandes au même hôte cloudfront avec différents chemins d'URI alors que la collecte continue.

1021

Si vous ne voyez pas ces demandes, assurez-vous d'avoir :

  1. accédé à votre application Web Native en utilisant le même nom de domaine spécifié pour Domaine autorisé lors de l'Intégration de votre application native.
  2. correctement chargé le Browser SDK pour démarrer la collecte et détection d'accès adaptatif comme décrit dans Assurer que la collecte se termine
  3. exposé la ressource statique comme décrit dans Héberger une ressource statique bien connue

La collecte ne s'est pas achevée

Lorsque le Browser SDK est initialisé avec startAdaptiveV1('<snippet host>', '<snippet ID>'); la collecte commencera. Seulement une fois que la promesse pour getSessionId() est retournée avec l'ID de session, le formulaire de connexion devrait être soumis.

Si vous soumettez le formulaire de connexion avant qu'un ID de session soit disponible, un "error":"adaptive_more_info_required" sera retourné de l'appel assessPolicy(context) ou refresh(context, refreshToken) du Proxy SDK.

Assurez-vous d'avoir mis à jour votre page de connexion pour assurer qu'un ID de session est disponible de getSessionId() avant la soumission du formulaire de connexion. Référez-vous aux options décrites dans Assurer que la collecte se termine.

Gestion des réponses d'erreur

Lorsqu'il y a Données insuffisantes pour compléter une évaluation, un statut d'erreur est retourné. À moins que des appels d'évaluation supplémentaires (assessPolicy(context) ou refresh(context, refreshToken)) soient effectués, aucun événement ne sera généré.

Seulement après qu'un nombre d'appels de réévaluation infructueux aient été effectués, un événement Service de risque indisponible sera généré. Le niveau de risque Medium de la politique d'accès adaptatif sera retourné.

D'autres erreurs, telles que les erreurs de connexion, empêcheront également le Proxy SDK d'invoquer les API IBM Security Verify et retourneront un résultat d'erreur. Ces erreurs devraient également être gérées dans l'application Web Native.

Assurez-vous d'avoir :

  1. vérifié les paramètres de configuration de votre IBM Security Verify Adaptive Browser SDK.
    Le startAdaptiveV1('<snippet host>', '<snippet ID>'); devrait correspondre à l'extrait web d'appel généré lors de l'intégration d'application.
  2. vérifié les paramètres de configuration de votre IBM Security Verify Proxy SDK.
    Le tenantUrl, clientId et clientSecret passés à new Adaptive(<config>); doivent correspondre à votre définition d'application personnalisée.
    Référez-vous à Ajouter le Proxy SDK à un serveur d'application.
  3. géré l'"error":"adaptive_more_info_required" indiquant qu'il y avait des données insuffisantes ou incorrectes fournies dans le contexte.
    Référez-vous à Effectuer une recollecte pour gérer l'erreur du Proxy SDK
    avec l'extrait fourni.

Service de risque indisponible

Lorsqu'une évaluation d'accès adaptatif n'est pas disponible, l'action de politique correspondant au niveau de risque Medium de la politique d'accès adaptatif est retournée. L'événement et le rapport montreront la raison "Risk Service Unavailable - Medium Risk Applied.".

Cette erreur sera retournée quand :

  • une erreur récupérable, telle qu'une "error":"adaptive_more_info_required" est rencontrée plusieurs fois pour le même ID de session
  • une erreur non récupérable telle que des données de contexte incomplètes ou une interruption de service est rencontrée

Dans le rapport d'accès adaptatif :

  • La raison contiendra "Risk Service Unavailable - Medium Risk Applied."
  • L'ID de session peut contenir une valeur valide par exemple pp629e475c7b6fa646e5b7606a61b3bec35ebde151600944772 ou une valeur vide (-)
  • Les détails adaptatifs contiendront des valeurs vides (-) pour tous les indicateurs de risque
1344

Détails d'événement affichés pour la raison "service de risque indisponible".

Erreur récupérable

Pendant les erreurs récupérables, une évaluation d'accès adaptatif n'est pas disponible en raison de données insuffisantes incluant :

  • ID de session manquant ou invalide
  • non-correspondance de snippet id étant copié ou réutilisé entre les locataires IBM® Security Verify et les applications Web Natives
  • collecte incomplète

Seulement après plusieurs tentatives de collecte et d'évaluation correspondante infructueuses, le niveau de risque Medium de la politique d'accès adaptatif sera retourné.

Utilisez l'API de service d'événements ou le rapport d'accès adaptatif pour déterminer l'ID de session.

Erreur non récupérable

Lorsqu'une erreur non récupérable se produit, l'accès adaptatif n'est pas capable de retourner un résultat d'évaluation. Pour fournir un niveau de protection cohérent (échec fermé), l'action correspondant au niveau de risque Medium de la politique d'accès adaptatif est retournée.

Assurez-vous d'avoir :

  1. vérifié l'état actuel du système pour toute panne système connue
  2. vérifié que vous envoyez toutes les informations de contexte requises dans votre appel au proxy SDK

Décision d'évaluation inattendue

Si vous avez complété la corrélation d'ID de session et ne pouvez pas localiser un événement correspondant avec un ID de session correspondant dans soit l'événement de l'API de service d'événements ou le détail de rapport d'accès adaptatif, assurez-vous d'avoir :

  1. attaché une politique d'accès adaptatif.
    Si une politique d'accès est attachée à votre application Web Native et vous recevez une décision valide, mais aucun événement d'accès adaptatif n'est généré, cela indique que l'accès adaptatif n'a pas été invoqué.
  2. une Gestion des réponses d'erreur correcte.
    Si l'API n'a pas été invoquée correctement, une erreur est retournée du Proxy SDK qui doit être gérée. Si l'API a été invoquée correctement, mais qu'il y avait des données insuffisantes, une collecte supplémentaire peut être requise. Dans les deux cas, aucun événement n'est généré.

Si vous avez localisé un événement avec un ID de session corrélé, une évaluation d'accès adaptatif a été invoquée.

Changement dans les attributs utilisateur ou appareil

L'accès adaptatif utilise des insights d'identité profonds, à travers un moteur de calcul de risque sophistiqué (IBM Trusteer®), pour correspondre avec précision les politiques d'accès au profil utilisateur tout au long de leur interaction numérique avec l'application.
Pendant la collecte, détection et évaluation, l'ID de session peut avoir été évalué par le moteur de calcul de risque différemment du processus de test manuel attendu.
Une gamme d'indicateurs peut altérer le résultat d'évaluation incluant :

  • l'utilisateur n'était pas nouveau
  • l'utilisateur avait une MFA en attente d'une session précédente
  • les modèles de localisation, appareil ou comportementaux ont changé significativement
1344

Vue de détails d'événement pour "Accès avec un changement dans les attributs d'appareil"

Erreur de logique de politique d'accès

Les politiques d'accès combinent le résultat le plus risqué de l'accès adaptatif, réauthentification et toute règle de politique correspondante.
S'il n'y a pas de règles de politique, ou aucune n'est correspondante pendant l'évaluation, la Règle par défaut est utilisée pour la comparaison la plus risquée.

Assurez-vous d'avoir :

  1. configuré l'action correcte pour le niveau de risque attendu dans la politique d'accès adaptatif.
  2. validé que la Réauthentification et les Règles de politique n'ont pas retourné un résultat plus risqué.
    "rule_name" dans le JSON de l'API de service d'événements et Nom de règle dans le détail de rapport d'accès adaptatif indiquent le résultat le plus risqué pour l'évaluation de politique.
1344

Détail de rapport d'accès adaptatif pour nouvel utilisateur avec changement d'attributs

Multiples invocations de politique d'accès infructueuses

Lorsqu'une politique d'accès adaptatif a des données insuffisantes pour compléter une évaluation, une collecte supplémentaire est requise.
Si l'application Web Native a une Gestion des réponses d'erreur correcte, mais l'évaluation est infructueuse plusieurs fois, un événement Service de risque indisponible est généré et l'action risque moyen associée est invoquée.

Re-invocation de politique d'accès

Lorsqu'un défi MFA est retourné d'une évaluation de politique d'accès adaptatif et que le défi est complété avec succès, deux événements sont générés :

  1. l'événement de défi MFA initial
  2. un événement Allow pendant la réévaluation de politique

Si vous voyez l'événement défi MFA mais pas l'événement Allow subséquent, assurez-vous d'avoir :

  1. identifié les facteurs possibles dans la réponse requires de la fonction assessPolicy du IBM Security Verify Proxy SDK :

    {
"status": "requires",
"transactionId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"enrolledFactors": [{type:"emailotp", ...}, {type:"totp", ...}, ...]
}

  2. invoqué les fonctions generateXXXX (le cas échéant) et evaluateXXXX appropriées pour un de ces facteurs.

Obtenir un support

Si le processus de dépannage ne résout pas votre erreur, référez-vous au sujet IBM Security SaaS Support sous la section Dépannage et support du produit IBM Security Verify dans le IBM® Knowledge Center.

Assurez-vous d'avoir collecté MustGather obligatoire. Pendant le processus de dépannage, vous avez probablement déjà collecté une grande quantité des données MustGather requises.

📘

Fournir des données récentes

certaines des données MustGather sont sensibles au temps, veuillez vous assurer qu'elles sont récentes avant de contacter le support.

MustGather obligatoire

  • Nom d'hôte du locataire IBM Security Verify.
    Par exemple : https://<hostname>.verify.ibm.com
  • Hôte d'extrait d'accès adaptatif IBM Security Verify et ID d'extrait (disponible sur la page de configuration d'application).
    Par exemple : d1anfu45urknyg.cloudfront.net et 511843
  • Au moins un ID de session (disponible dans la console du navigateur).
    Par exemple : pp629e475c7b6fa646e5b7606a61b3bec35ebde151600944772

MustGather optionnel

  • ID de corrélation d'événement ou rapport.
    Par exemple : CORR_ID-ae2fea3c-66c1-4882-9c52-6130db5448dc
  • client_id IBM Security Verify (ne fournissez pas le secret).
    Par exemple : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
  • ID ou nom d'application IBM Security Verify.
    Par exemple : 4587066640521568871 ou My Native Web App
  • ID ou nom de politique d'accès IBM Security Verify.
    Par exemple : 357317 ou My Native Web App Adaptive access policy
  • Le code d'erreur et le message.
    Par exemple : CSIAQ0298E Adaptive access assessment unavailable. Session collection was not completed or interrupted.

Updated about 1 month ago