View a markdown version of this page

Configurer l'autorisateur JWT entrant - Base rocheuse de l'Amazonie AgentCore
Configuration d'un autorisateur entrant

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Configurer l'autorisateur JWT entrant

L'autorisateur entrant authentifie et autorise les demandes d'API OAuth 2.0 entrantes à Runtime et Gateway. AgentCore AgentCore Il valide les jetons Web JSON (JWT) avant d'autoriser l'accès aux agents ou aux passerelles. L'autorisateur est indépendant du fournisseur d'identité (IdP) et fonctionne avec n'importe quel fournisseur d'identité compatible avec OAuth 2.0. Lorsque AgentCore Runtime ou AgentCore Gateway reçoit une demande entrante, l'autorisateur utilise l'URL de découverte configurée pour récupérer les clés publiques et le point de terminaison du serveur d'autorisation pour effectuer la validation JWT. Vous pouvez configurer l'autorisateur en fonction de votre IdP et des étendues d'autorisation ou des revendications autorisées.

Configuration d'un autorisateur entrant

Vous pouvez configurer l'environnement d'exécution de votre agent (voir CreateAgentRuntime) ou votre passerelle (voir CreateGateway) pour accepter les jetons JWT bearer en fournissant une configuration d'autorisation lors de la création de l'agent ou de la passerelle. La configuration des autorisations (voir CustomJWTAuthorizerConfiguration) est la même pour AgentCore Runtime ou AgentCore Gateway.

  • URL de découverte  : chaîne qui doit correspondre au modèle des URL ^.+/\.well-known/openid-configuration$ de découverte OpenID Connect (OIDC). Vous pouvez trouver votre URL de découverte auprès de votre fournisseur d'identité. Une URL de découverte est une adresse Web spécifique qu' AgentCore Identity peut utiliser pour trouver des informations sur les détails du point de terminaison d'authentification. Il permet à AgentCore Identity d'accepter de manière dynamique les jetons émis par votre fournisseur d'identité OIDC sans intégration explicite.

  • Audiences autorisées  : liste des audiences autorisées que AgentCore Identity validera par rapport à la aud réclamation figurant dans le jeton JWT. Une demande d'audience (aud) dans OAuth 2.0 spécifie à quel serveur de ressources (API) le jeton est destiné. Le serveur de ressources valide la aud réclamation pour s'assurer qu'il s'agit du bon destinataire avant de traiter la demande, empêchant ainsi la réutilisation d'un jeton sur une autre API pour laquelle il n'a pas été émis.

  • Clients autorisés  : liste d'identifiants de clients autorisés que AgentCore Identity validera par rapport à la client_id réclamation contenue dans le jeton JWT. client_idDans OAuth 2.0, A est un identifiant public unique pour une application qui demande des jetons d'accès pour accéder à AgentCore Runtime ou AgentCore Gateway. Il agit comme un nom d'utilisateur pour l'application, la distinguant des autres clients (applications) enregistrés auprès de l'autorisateur.

  • Étendues autorisées  : liste des autorisations autorisées, définies comme des étendues, autorisées à invoquer le moteur d'exécution ou la passerelle. Si elle est configurée, au moins une valeur d'étendue du jeton entrant doit correspondre à l'une des valeurs configurées. Une portée OAuth 2.0 est une chaîne qui définit un niveau d'accès spécifique défini dans le JWT. Les étendues agissent comme des autorisations pour limiter ce que peut faire une application.

  • Réclamations personnalisées requises (voir CustomClaimValidationType)  : ensemble de règles permettant de faire correspondre les revendications spécifiques du jeton entrant à des valeurs prédéfinies pour la validation des jetons JWT. Vous pouvez créer une règle en spécifiant les éléments suivants :

    • InboundTokenClaimName: nom de la réclamation personnalisée.

    • InboundTokenClaimValueType: L'un STRING ou l'autreSTRING_ARRAY.

    • AuthorizingClaimMatchValue: valeur requise et opérateur de comparaison de la revendication personnalisée.

      • ClaimMatchValue: valeur requise de la réclamation personnalisée.

      • ClaimMatchOperator: Si InboundTokenClaimValueType c'est égalSTRING, cela doit être le casEQUALS. Si InboundTokenClaimValueType c'est égalSTRING_ARRAY, cela peut être CONTAINS ouCONTAINS_ANY.

      • Exemple  : Vous pouvez définir une règle qui applique :Group must equal Developer.

  • Remarque  : Au moins un des champs est obligatoire pour la configuration : audiences autorisées, clients autorisés, étendues autorisées ou revendications personnalisées obligatoires. Si plusieurs sont utilisés, l'autorisateur les vérifiera tous.