Résolution des problèmes liés au périmètre de REST API

  • Rversion finale: Washingtondc
  • Mis à jour 1 févr. 2024
  • 3 minutes de lecture

    • Les actions de dépannage peuvent aider à résoudre les problèmes courants lors de la configuration ou de l’exécution du périmètre de l’API REST.

    Tableau 1. Dépannage
    Problème Action
    L’API REST est liée au périmètre d’authentification, mais pendant l’exécution, il n’y a pas de vérification du périmètre d’authentification, même à l’aide de l’authentification par jeton de porteur.
    • Assurez-vous que l’enregistrement sys_api_access_policy est actif. L’exécution ignore les enregistrements inactifs.
    • Vérifiez si la propriété com.glide.rest.api.auth.scope.check.enable est définie sur faux.
    • Vérifiez si le jeton OAuth a un périmètre d’authentification useraccount .
    L’API REST est liée à auth_scope1, mais le jeton d’accès qui a auth_scope2 est également en mesure d’y accéder.
    • Vérifiez si cet enregistrement est actif.
    • Vérifiez ce REST, vérifiez s’il existe d’autres enregistrements qui ont les mêmes API mais qui appliquent des méthodes, des versions ou des ressources différentes.
    L’API REST est liée au périmètre d’authentification, mais pendant l’exécution, il n’y a pas de vérification du périmètre d’authentification pour basicAuth et mutualAuth. Elle est attendue, car le périmètre d’authentification de l’API REST ne s’applique qu’au jeton d’accès OAuth ou au jeton OIDC. Il n’applique pas l’authentification de base, les cookies de session et l’authentification basée sur les certificats.
    L’appel d’API REST renvoie une erreur 403 lors de l’utilisation du jeton d’accès OAuth. Vérifiez le message d’erreur « Missing required required access scope » (Périmètre d’accès API requis manquant). Si une valeur est trouvée, la vérification du périmètre d’authentification échoue pour cette REST API
    Le compte utilisateur prédéfini est supprimé et pas sûr d’être restauré. Exportez un compte utilisateur au format XML à partir de l’autre instance et importez-le ou créez un compte utilisateur et modifiez la propriété glide.oauth.token.scope.useraccount système dans l’enregistrement de sys_id nouvellement créé.

    Forum Aux Questions

    Voici quelques-unes des questions fréquemment posées lors de l’utilisation du périmètre d’authentification de l’API REST :

    Un jeton OAuth peut-il être lié à plusieurs périmètres d’authentification ?
    Oui, un oauth_entity peut être lié à plusieurs périmètres d’authentification, chaque jeton OAuth émis par ce oauth_entity a les mêmes périmètres d’authentification.
    Différents jetons OAuth avec des périmètres d’authentification différents peuvent-ils accéder à la même REST API ?
    Oui, pour la même API REST, il est possible d’y accéder via différents champs d’application d’authentification. Tant qu’un champ d’application d’authentification correspond, celui-ci renvoie les résultats.
    Le jeton d’accès OAuth avec le périmètre d’authentification useraccount peut-il accéder à n’importe quelle API REST ?
    Oui, le compte utilisateur dispose d’un accès complet au périmètre d’authentification .
    Le périmètre OAuth du jeton d’accès OAuth peut-il être modifié dynamiquement ?
    Oui, le champ d’application de l’authentification n’est pas codé en dur avec le jeton d’accès de la table oauth_credential . Au lieu de cela, le champ d’application d’authentification est obtenu à partir de oauth_entity liées pendant l’exécution.
    Le jeton OAuth peut-il conserver les mêmes étendues d’authentification après l’actualisation ?
    Oui, le champ d’application d’authentification ne changera pas après l’actualisation du jeton, sauf oauth_admin modifier le champ d’application d’authentification lié à oauth_entity.
    L’enregistrement du périmètre d’authentification useraccount prédéfini est supprimé. Est-il possible de créer un nouveau périmètre d’authentification portant le nom useraccount ?
    La création d’un nouveau champ d’application d’authentification avec le même compte d’utilisateur ne fonctionne pas. Lors de l’exécution, il utilise le sys_id au lieu du nom pour effectuer la vérification du périmètre d’authentification et modifier la propriété glide.oauth.token.scope.useraccount système en tant qu’enregistrement de sys_id nouvellement créé.
    Si l’administrateur modifie l’authentification dans le champ d’application lié à oauth_entity, tous les jetons d’accès OAuth existants émis par cette entité OAuth sont-ils également modifiés ?
    Oui, le périmètre d’authentification n’est pas directement lié au jeton d’accès OAuth, il est obtenu à partir de oauth_entity pendant l’exécution.
    Différents jetons d’accès OAuth émis par la même oauth_entity peuvent-ils avoir des périmètres d’authentification différents ?
    Non, tous les accès au jeton sont émis par la même oauth_entity et ont toujours les mêmes étendues d’authentification.
    Un utilisateur peut-il définir différents périmètres d’authentification pour un point de terminaison particulier ?
    Non, il existe une vérification de contrainte unique pour un point de terminaison de REST API particulier. Toutefois, pour le même point de terminaison d’API REST, il peut avoir plusieurs champs d’application d’authentification correspondants.
    La vérification du champ d’application d’authentification est-elle également utilisée pour BasicAuth ?
    Non, la vérification du périmètre d’authentification concerne uniquement le jeton d’accès OAuth et le jeton OIDC, elle n’est pas demandée basicAuth et mutualAuth