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 Verify peut vous aider à vous orienter dans la bonne direction.

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

Pas de saisie 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 l'une ou l'autre des situations suivantes :

1344

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

Pas de politique d'accès adaptatif

Dans une politique d'accès adaptative, les règles de post-authentification font appel à une évaluation.

Vérifiez quelle politique d'accès est jointe à votre demande. Embarquer une application native:

1344

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

Assurez-vous que la case Accès adaptatif est cochée dans cette politique d'accès :

1344

Activer la case à cocher de l'accès adaptatif dans la politique

🚧

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

Si vous ne voyez pas d'accès adaptatif dans votre politique d'accès, assurez-vous qu'il s'agit d'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 de subvention

Assurez-vous que la politique d'accès est appliquée à JWT Bearer dans la section Apply access policy to API grant types de la définition de l'application. Si vous ne voyez pas d'événement attendu lors d'un flux d'un autre type de subvention (par exemple, un flux d'actualisation), assurez-vous que ce type de subvention est également sélectionné.

Voir l'exemple du type de subvention refresh ici.

Données insuffisantes

Lors de l'utilisation du Proxy SDK pour l'authentification d'un utilisateur, la fonction adaptive.assessPolicy(context) nécessite une adresse context similaire à :

var context = {
    sessionId : req.body.sessionId, // The generated session ID posted from the browser
    userAgent : req.headers['user-agent'], // The user-agent collected from headers
    ipAddress : req.ip // The source address of the IP connection.
};

Assurez-vous d'avoir :

  1. a invoqué le site getSessionId() à partir du SDK du navigateur.
    Pour plus de détails sur la manière d'invoquer correctement le site getSessionId(), reportez-vous à la rubrique " Assurer l'achèvement de la collecte".
  2. a traité le site "error": "adaptive_more_info_required" en indiquant que les données fournies dans le contexte étaient insuffisantes ou incorrectes.
    Reportez-vous à Perform Recollection pour traiter l'erreur du Proxy SDK à l'aide de 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'authentification d'un utilisateur via le Proxy SDK, l'adresse ipAddress définie dans l'objet context doit être une adresse IP routable sur Internet.

Les adresses IP non valides, telles que les adresses de bouclage ( :::1, 127.0.0.* ), les adresses non routables et les adresses IP internes ( 192.168.0.* ), entraînent une non-concordance entre l'adresse IP collectée par le navigateur de l'utilisateur et l'adresse IP signalée par le Proxy SDK. Cette incompatibilité empêche l'exécution du flux policyAuth.

Généralement, lorsque le Proxy SDK est déployé en tant qu'application conteneurisée dans des environnements hors production, la valeur req.ip est une adresse de bouclage entre l'application compatible avec Adaptive et les conteneurs Proxy. Lorsque cette valeur est transmise dans le flux, une erreur se produit en raison d'une adresse IP de transfert non valide.

var context = {
    sessionId : req.body.sessionId,
    userAgent : req.headers['user-agent'],
    ipAddress : req.ip // This value may contain an invalid value such as a loopback address.
};

Pour résoudre ce problème, assurez-vous que l'adresse IP fournie est accessible via l'internet et qu'elle ne représente pas une adresse de bouclage. Utiliser explicitement l'adresse IP du navigateur de l'utilisateur, plutôt que de l'extraire de la requête.

var context = {
    sessionId : req.body.sessionId,
    userAgent : req.headers['user-agent'],
    ipAddress : "<IP address of the user's browser>" // Updated IP to avoid unexpected values
};

Lors de l'authentification, cette modification garantit que le champ ipAddress correspond à ce qui est recueilli dans la collection de navigateurs de l'utilisateur. Il garantit également que l'adresse IP réelle du navigateur de l'utilisateur est utilisée. Ce correctif n'est applicable que lorsque l'application est exécutée localement. Comme vous vous connectez à l'application sur votre propre appareil, l'adresse IP extraite est pas l'IP externe du serveur, mais l'IP du conteneur local.

❗️

Mise à jour de ipAddress avec une valeur fixe dans les environnements locaux et 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 sont exécutés localement.

Dans un environnement de production, l'application adaptative doit indiquer au Proxy SDK l'adresse IP réelle du navigateur de l'utilisateur. Elle doit correspondre à la valeur de l'adresse IP collectée à partir du navigateur de l'utilisateur.

La collecte n'a pas commencé

Lorsque le SDK du navigateur est initialisé sur la page de connexion, comme décrit dans Veiller à ce que la collecte soit complète, si la collecte ne démarre pas, aucun ID de session ne sera fourni et l'appel à getSessionId() ne renverra pas la bonne valeur.

Utilisez les Developer Tools 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 doivent renvoyer un code de réponse 200 avec un corps de réponse non vide.

De plus, vous devriez voir plusieurs requêtes vers le même hôte cloudfront avec des chemins URI différents au fur et à mesure que la collecte se poursuit.

1021

Si vous ne voyez pas ces demandes, assurez-vous que vous les avez faites :

  1. accédez à votre application Web native en utilisant le même nom de domaine que celui spécifié pour Allowed domain lors de l'intégration de votre application native.
  2. avoir correctement chargé le SDK du navigateur pour lancer la collecte et la détection de l'accès adaptatif, comme décrit dans la section S'assurer que la collecte est terminée
  3. exposer la ressource statique comme décrit dans Hébergement d'une ressource statique connue

La collecte n'est pas terminée

Lorsque le SDK du navigateur est initialisé avec startAdaptiveV1('<snippet host>', '<snippet ID>');, la collecte commence. Ce n'est qu'une fois que la promesse de getSessionId() est renvoyée avec l'identifiant de session que le formulaire de connexion doit être soumis.

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

Assurez-vous d'avoir mis à jour votre page de connexion pour qu'un identifiant de session soit disponible sur getSessionId() avant la soumission du formulaire de connexion. Se référer aux options décrites dans la section Assurer l'achèvement de la collecte.

Gestion des réponses d'erreur

Lorsque les données sont insuffisantes pour compléter une évaluation, un statut d'erreur est renvoyé. Aucun événement ne sera généré si des appels d'évaluation supplémentaires ( assessPolicy(context) ou refresh(context, refreshToken) ) ne sont pas effectués.

Ce n'est qu'après un certain nombre d'appels de réévaluation infructueux qu'un événement de service de risque indisponible sera généré. Le niveau de risque Medium de la politique d'accès adaptative sera renvoyé.

D'autres erreurs, telles que des erreurs de connexion, empêcheront également le Proxy SDK d'invoquer les API IBM Verify et renverront un résultat d'erreur. Ces erreurs doivent également être traitées dans l'application Web native.

Assurez-vous d'avoir :

  1. a vérifié les paramètres de configuration de votre IBM Verify Adaptive Browser SDK.
    Le site startAdaptiveV1('<snippet host>', '<snippet ID>'); doit correspondre à l'extrait de web d'appel généré lors de l'introduction de la demande.
  2. a vérifié les paramètres de configuration de votre IBM Verify Proxy SDK.
    Les adresses tenantUrl, clientId et clientSecret transmises à new Adaptive(<config>); doivent correspondre à la définition de votre application personnalisée.
    Reportez-vous à la section Ajout du Proxy SDK à un serveur d'application.
  3. a traité le site "error": "adaptive_more_info_required" en indiquant que les données fournies dans le contexte étaient insuffisantes ou incorrectes.
    Se référer à Perform Recollection pour traiter l'erreur du Proxy SDK
    avec l'extrait fourni.

Service de gestion des risques indisponible

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

Cette erreur est renvoyée lorsque

  • une erreur récupérable, telle que "error": "adaptive_more_info_required", est rencontrée plusieurs fois pour la même session
  • une erreur irrécupérable, telle que des données contextuelles incomplètes ou une interruption de service, est rencontrée

Dans le rapport sur l'accès adaptatif :

  • L'exposé des motifs contiendra "Risk Service Unavailable - Medium Risk Applied."
  • L'identifiant 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

Event details shown for "risk service unavailable" reason.

Erreur récupérable

En cas d'erreur récupérable, l'évaluation de l'accès adaptatif n'est pas disponible en raison de l'insuffisance des données incluses :

  • iD de session manquant ou invalide
  • inadéquation de snippet id copié ou réutilisé entre les locataires de IBM® Verify et les applications Web natives
  • collection incomplète

Ce n'est qu'après plusieurs tentatives infructueuses de collecte et d'évaluation correspondante que le niveau de risque Medium de la politique d'accès adaptative sera renvoyé.

Utilisez l'API du service des événements ou le rapport d'accès adaptatif pour déterminer l'adresse Session ID.

Erreur non récupérable

Lorsqu'une erreur irrécupérable se produit, l'accès adaptatif n'est pas en mesure de renvoyer un résultat d'évaluation. Pour assurer un niveau de protection cohérent (échec fermé), l'action correspondant au niveau de risque Medium de la politique d'accès adaptative est renvoyée.

Assurez-vous d'avoir :

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

Décision d'évaluation inattendue

Si vous avez terminé la corrélation des identifiants de session et que vous ne parvenez pas à localiser un événement correspondant à Session ID dans l'événement API du service Events ou dans les détails du rapport Adaptive Access, assurez-vous que vous l'avez fait :

  1. joint une politique d'accès adaptative.
    Si une politique d'accès est attachée à votre application Web native et que vous recevez une décision valide, mais qu'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. correct Gestion des réponses d'erreur.
    Si l'API n'a pas été invoquée correctement, le Proxy SDK renvoie une erreur qui doit être traitée. Si l'API a été invoquée correctement, mais que les données étaient insuffisantes, une collecte supplémentaire peut être nécessaire. Dans les deux cas, aucun événement n'est généré.

Si vous avez repéré un événement en corrélation avec Session ID, une évaluation de l'accès adaptatif a été déclenchée.

Modification des attributs de l'utilisateur ou de l'appareil

L'accès adaptatif utilise une connaissance approfondie de l'identité, grâce à un moteur sophistiqué de calcul des risques ( IBM Trusteer®), pour adapter avec précision les politiques d'accès au profil de l'utilisateur tout au long de son interaction numérique avec l'application.
Lors de la collecte, de la détection et de l'évaluation, il se peut que le moteur de calcul des risques ait évalué le site Session ID différemment du processus de test manuel prévu.
Une série d'indicateurs peuvent modifier le résultat de l'évaluation, notamment

  • l'utilisateur n'était pas nouveau
  • l'utilisateur avait un AMF en suspens lors d'une session précédente
  • la localisation, l'appareil ou les habitudes comportementales ont changé de manière significative
1344

Event details view for "Access with a change in device attributes"

Erreur de logique de la politique d'accès

Les politiques d'accès combinent les résultats les plus risqués de l'accès adaptatif, de la réauthentification et de toute règle de politique correspondante.
S'il n'y a pas de règles de politique générale ou si aucune ne correspond pendant l'évaluation, le site Default rule est utilisé 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 adaptative.
  2. a validé le fait que les sites Reauthentication et Policy rules n'ont pas donné un résultat plus risqué.
    "rule_name" dans le JSON Service d'événements API et Rule name dans le détail Détail du rapport sur l'accès adaptatif indiquent le résultat le plus risqué pour l'évaluation de la politique.
1344

Adaptive access report detail for new user with change of attributes

Plusieurs invocations infructueuses de la politique d'accès

Lorsqu'une politique d'accès adaptatif ne dispose pas de données suffisantes pour réaliser une évaluation, une collecte supplémentaire est nécessaire.
Si l'application Web native a une adresse Gestion des réponses d'erreur correcte, mais que l'évaluation échoue plusieurs fois, un événement Service de gestion des risques indisponible est généré et l'action risque moyen associée est invoquée.

Réinvocation de la politique d'accès

Lorsque l'évaluation d'une politique d'accès adaptative renvoie une demande d'accès à l'AMF et que cette demande est acceptée, deux événements sont générés :

  1. l'événement initial de l'AMF
  2. un événement de type "Allow" au cours de la réévaluation de la police

Si vous voyez l'événement de défi de l'AMF mais pas l'événement d' allocation suivant, assurez-vous que vous l'avez fait :

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

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

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

Obtenir un soutien

Si le processus de dépannage ne résout pas votre erreur, reportez-vous à la rubrique IBM Security SaaS Support dans la section Troubleshooting and support du produit IBM Verify dans le Centre de connaissances IBM®.

Assurez-vous d'avoir collecté Obligatoire MustGather. Au cours du processus de dépannage, vous aurez probablement déjà recueilli une grande partie des données requises sur le site MustGather.

📘

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 service d'assistance.

Obligatoire MustGather

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

MustGather facultative

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

Updated 30 days ago