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.

Configurez l'autorisation entrante pour votre passerelle

Avant de créer votre passerelle, vous devez configurer l'autorisation entrante. L'autorisation entrante valide les utilisateurs qui tentent d'accéder à des cibles via votre AgentCore passerelle. AgentCore prend en charge les types d'autorisation entrante suivants :

Si vous ne prévoyez pas d'utiliser la configuration d'autorisation par défaut à l'aide d'Amazon Cognito, sélectionnez la rubrique correspondant au type d'autorisation que vous comptez utiliser pour savoir comment la configurer :

IAM-based autorisation entrante

IAM-based l'autorisation entrante vous permet d'utiliser les informations d'identification IAM de l'appelant de la passerelle pour l'autorisation. Vous pouvez utiliser cette option si vous souhaitez créer une identité IAM permettant d'authentifier les utilisateurs qui appellent votre passerelle.

Pour configurer l'autorisation IAM-based entrante

Exemple de stratégie

L'exemple suivant montre une politique que vous pouvez associer à une identité pour lui permettre d'invoquer une passerelle avec cet ID. my-gateway-12345

{
"Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowGatewayInvocation",
      "Effect": "Allow",
      "Action": [
        "bedrock-agentcore:InvokeGateway"
      ],
      "Resource": [
        "arn:aws:bedrock-agentcore:us-east-1:123456789012:gateway/my-gateway-12345"
      ]
    }
  ]
}

Ressources

Autorisation entrante basée sur JSON Web Token (JWT)

Un jeton Web JSON (JWT) est un jeton sécurisé et compact utilisé pour l'autorisation. Vous pouvez créer un JWT avec un fournisseur d'identité pris en charge. Après avoir créé un JWT, vous pouvez le récupérer et le spécifier comme configuration d'autorisation lorsque vous créez la passerelle.

Vous pouvez utiliser la AgentCore CLI pour configurer une passerelle avec un fournisseur d'identité JWT existant. Pour en savoir plus sur les méthodes de configuration JWT, sélectionnez l'une des rubriques suivantes :

Configurer un autorisateur JWT

Créez une application et un client avec un fournisseur d'identité pris en charge. Pour un exemple Amazon Cognito, consultez la section Commencer à utiliser Amazon Cognito. Notez l'URL de découverte OIDC et l'ID client.

Exécutez la commande suivante dans le répertoire d'un AgentCore projet :

agentcore add gateway \
  --name MyGateway \
  --protocol-type MCP \
  --authorizer-type CUSTOM_JWT \
  --discovery-url <OIDC_DISCOVERY_URL> \
  --allowed-clients <CLIENT_ID>

La AgentCore CLI utilise la configuration OIDC existante ; elle ne crée pas les ressources du fournisseur d'identité. Pour invoquer la passerelle, procurez-vous un jeton d'accès auprès de votre fournisseur. Pour Amazon Cognito, consultez la section Le point de terminaison de l'émetteur du jeton dans le guide du développeur Amazon Cognito.

Configurer un JWT manuellement

Amazon Bedrock AgentCore prend en charge les JWT de tous les fournisseurs d'identité. Vous pouvez voir quelques exemples sur la page Configuration et configuration du fournisseur.

Lors de la création du JWT, prenez note des valeurs suivantes, que vous devrez remplir CustomJWTAuthorizerConfiguration lors de la création d'une passerelle, si elles s'appliquent à votre cas d'utilisation :

Vous aurez besoin de ces valeurs pour effectuer les opérations suivantes :

Portez la publicité dans les défis d'authentification

Lorsqu'un client envoie une demande à une JWT-authorized passerelle sans jeton d'accès valide, la passerelle renvoie une réponse d'erreur avec un WWW-Authenticate en-tête qui annonce les étendues OAuth requises. Cela suit le format de défi de jetons RFC 6750 Bearer et permet aux MCP-compliant clients de découvrir automatiquement les étendues nécessaires à l'acquisition de jetons.

La passerelle renvoie les réponses suivantes en fonction de l'erreur :

La scope valeur contient les étendues délimitées par des espaces configurées comme étendues autorisées dans la passerelle. CustomJWTAuthorizerConfiguration La resource_metadata valeur pointe vers le document de métadonnées des ressources protégées OAuth de la passerelle/.well-known/oauth-protected-resource, que les clients peuvent récupérer pour découvrir le serveur d'autorisation et les étendues prises en charge.

Utiliser un fournisseur d'identité privé (VPC-hosted)

AgentCore Gateway prend en charge JWT-based l'autorisation entrante auprès des fournisseurs d'identité hébergés dans votre VPC. Vous pouvez configurer un privateEndpoint sur le customJWTAuthorizer pour permettre d'accéder AgentCore à vos points de terminaison OIDC privés de découverte, de jeton et de JWKS sans les exposer à l'Internet public.

Votre responsable IAM doit disposer de l'iam:CreateServiceLinkedRoleautorisation pouridentity-network.bedrock-agentcore.amazonaws.com, afin qu' AgentCore Identity puisse créer le rôle AWSServiceRoleForBedrockAgentCoreIdentity lié au service en votre nom s'il n'existe pas déjà.

privateEndpointCela s'applique au domaine dudiscoveryUrl. Si votre fournisseur d'identité utilise des domaines différents pour d'autres points de terminaison (par exemple, le jeton ou le point de terminaison JWKS renvoie à un domaine différent de celui de l'URL de découverte), utilisez cette option privateEndpointOverrides pour spécifier une configuration de point de terminaison privé distincte pour chaque domaine supplémentaire.

L'exemple suivant crée une passerelle avec un fournisseur d'identité privé à l'aide de Lattice géré :

{
  "name": "my-private-idp-gateway",
  "protocolType": "MCP",
  "roleArn": "arn:aws:iam::123456789012:role/my-gateway-role",
  "authorizerType": "CUSTOM_JWT",
  "authorizerConfiguration": {
    "customJWTAuthorizer": {
      "allowedAudience": [
        "my-audience"
      ],
      "discoveryUrl": "https://my-idp.internal.example.com/.well-known/openid-configuration",
      "privateEndpoint": {
        "managedVpcResource": {
          "vpcIdentifier": "vpc-0abc123def456",
          "subnetIds": ["subnet-0abc123", "subnet-0def456"],
          "endpointIpAddressType": "IPV4",
          "securityGroupIds": ["sg-0abc123def"]
        }
      }
    }
  }
}

Si votre jeton ou vos points de terminaison JWKS utilisent un domaine différent de celui de l'URL de découverte, ajoutez une privateEndpointOverrides entrée pour chaque domaine supplémentaire. Actuellement, n'privateEndpointOverridesest pris en charge qu'avec les ressources Lattice autogérées :

{
  ...
  "authorizerConfiguration": {
    "customJWTAuthorizer": {
      "allowedAudience": ["my-audience"],
      "discoveryUrl": "https://my-idp.internal.example.com/.well-known/openid-configuration",
      "privateEndpoint": {
        "selfManagedLatticeResource": {
          "resourceConfigurationIdentifier": "arn:aws:vpc-lattice:us-east-1:123456789012:resourceconfiguration/rcfg-abc123"
        }
      },
      "privateEndpointOverrides": [
        {
          "domain": "my-token-server.internal.example.com",
          "privateEndpoint": {
            "selfManagedLatticeResource": {
              "resourceConfigurationIdentifier": "arn:aws:vpc-lattice:us-east-1:123456789012:resourceconfiguration/rcfg-def456"
            }
          }
        }
      ]
    }
  }
}

Pour connaître Lattice autogéré, les configurations multicomptes et les configurations avancées, consultez Connexion à des ressources privées de votre VPC à l'aide de VPC Lattice. Pour un guide complet couvrant les scénarios d'IdP privés entrants et sortants, voir Connexion à des fournisseurs d'identité privés.

Autorisation entrante déchargée

Avec l'autorisation entrante déchargée, la passerelle ne prend aucune décision d'autorisation de sa propre initiative. Au lieu de cela, il délègue l'autorisation à un autre composant :

AgentCore propose deux types de fichiers déchargés :

Quel que soit le type, vous décidez où l'autorisation est réellement appliquée :

Authenticate-only autorisation

Avec l'autorisation d'authentification uniquement (AUTHENTICATE_ONLY), la passerelle vérifie la signature Signature Version 4 (Sigv4) de l'appelant pour confirmer son identité, mais ne prend aucune décision d'autorisation de sa propre initiative. Tout principal IAM authentifié peut invoquer la passerelle quelles que soient ses autorisations, et la demande est transmise à la cible. L'autorisation est déléguée au service cible en aval ou à un moteur de politique connecté à la passerelle.

Aucune autorisation

Vous pouvez créer une passerelle configurée sans autorisation à l'aide deauthorizerType=NONE. La passerelle n'effectuera aucune autorisation sur la demande de passerelle entrante et celle-ci peut ne pas être authentifiée.

Meilleures pratiques en matière de sécurité

Intégrer un environnement d'exécution existant sans modifier son authentification

Lorsque vous associez un type entrant déchargé à un type d'autorisation sortant correspondant qui transmet l'identité de l'appelant au moteur d'exécution, l'intégration à une passerelle peut être aussi simple que de définir un remplacement de point de terminaison sur votre client existant. Aucune modification d'authentification n'est requise :