Dépannage de l'accès adaptatif
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 trouvée
- Service de risque indisponible dans l'entrée d'événement ou de rapport
- Décision d'évaluation inattendue
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 :
- il n'y a pas de politique d'accès adaptatif associée à l'application web native
- la politique d'accès n'est pas appliquée au type d'octroi utilisé.
- des données insuffisantes ont été fournies au point de terminaison
/token
- la collecte n'a pas commencé.
- la collecte ne s'est pas achevée.
- une réponse d'erreur (ou aucune réponse) du Proxy SDK n'a pas été gérée correctement et aucune autre tentative n'a été effectuée.

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 :

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 :

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 :
- invoqué le
getSessionId()
depuis le Browser SDK.
Référez-vous à Assurer que la collecte se termine pour les détails sur comment invoquergetSessionId()
correctement. - 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.

Si vous ne voyez pas ces demandes, assurez-vous d'avoir :
- 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. - 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
- 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 :
- vérifié les paramètres de configuration de votre IBM Security Verify Adaptive Browser SDK.
LestartAdaptiveV1('<snippet host>', '<snippet ID>');
devrait correspondre à l'extrait web d'appel généré lors de l'intégration d'application. - vérifié les paramètres de configuration de votre IBM Security Verify Proxy SDK.
LetenantUrl
,clientId
etclientSecret
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. - 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

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
.
- Si aucun
ID de session
n'est disponible, référez-vous à - S'il y a un
ID de session
dans l'événement ou le rapport, vérifiez l'état actuel du système pour toute panne système connue.
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 :
- vérifié l'état actuel du système pour toute panne système connue
- 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 :
- 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é. - 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

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 :
- configuré l'action correcte pour le niveau de risque attendu dans la politique d'accès adaptatif.
- validé que la
Réauthentification
et lesRè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 etNom 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.

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 :
- l'événement de défi MFA initial
- 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 :
-
identifié les facteurs possibles dans la réponse
requires
de la fonctionassessPolicy
du IBM Security Verify Proxy SDK :{ "status": "requires", "transactionId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "enrolledFactors": [{type:"emailotp", ...}, {type:"totp", ...}, ...] }
-
invoqué les fonctions
generateXXXX
(le cas échéant) etevaluateXXXX
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
et511843
- 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
ouMy Native Web App
- ID ou nom de politique d'accès IBM Security Verify.
Par exemple :357317
ouMy 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 21 days ago