Authentication
Configurez l'authentification entrante pour contrôler l'accès aux agents et l'authentification sortante pour accéder en toute sécurité aux ressources OCI.
Configurer l'authentification sur l'application hébergée. Les déploiements hébergés associés héritent de ces paramètres. Sélectionnez un jeton de porteur de domaine d'identité, une session de navigateur de domaine d'identité, OCI IAM ou Aucune authentification en fonction de la façon dont les clients accèdent à l'application.
Authentification entrante
L'authentification entrante contrôle qui peut accéder à vos agents hébergés. Les applications hébergées prennent en charge les options d'authentification suivantes :
- Jeton du porteur du domaine d'identité : Les clients envoient un jeton d'accès OAuth émis par un domaine d'identité IAM OCI. Le service valide le jeton avant d'acheminer la demande vers le déploiement hébergé. Voir Configuration de l'authentification par jeton de porteur de domaine d'identité.
- Session du navigateur de domaine d'identité : Utilise le flux de code d'autorisation OAuth 2.1 avec la clé de vérification pour l'échange de code (PKCE). Les utilisateurs du navigateur sont redirigés vers un domaine d'identité OCI pour se connecter. Le service d'application hébergé obtient un jeton d'accès en son nom et établit une session de navigateur qui utilise un témoin de session. Voir Session du navigateur de domaine d'identité.
- OCI IAM : Les clients signent des demandes conformément aux exigences de signature des demandes OCI IAM. Voir Authentification.
- Aucune authentification : La plate-forme achemine les demandes sans authentifier l'appelant. Utilisez cette option pour le contenu public ou lorsque votre application gère l'authentification. Voir Aucune authentification.
Pour la configuration d'API, voir InboundAuthConfig. Pour l'authentification de domaine d'identité, voir aussi IdcsAuthConfig. Omettre idcsConfig lors de l'utilisation de NO_AUTH_CONFIG.
Consultez le type d'authentification sélectionné dans l'onglet Configuration de l'application.
Utilisation sans authentification
Sélectionnez Aucune authentification lorsque la plate-forme n'a pas besoin d'authentifier les demandes entrantes. Par exemple, le contenu Web public, les applications avec leur propre flux de connexion et les intégrations de service où l'application valide les données d'identification.
Toute personne pouvant atteindre le point d'extrémité peut envoyer des demandes sans authentification gérée par la plate-forme. Si l'accès nécessite une restriction, implémentez l'authentification et l'autorisation dans votre application. Les paramètres réseau déterminent quels clients peuvent atteindre le point d'extrémité.
Aucune inscription de location distincte n'est requise. TLS, le point d'extrémité public ou privé configuré et les limites de service s'appliquent toujours. Les autorisations IAM d'OCI sont toujours requises pour gérer l'application et accéder à d'autres services OCI à partir de celle-ci.
Lors de l'utilisation de l'API, réglez inboundAuthConfig.inboundAuthConfigType à NO_AUTH_CONFIG et omettez idcsConfig. Si vous omettez inboundAuthConfig d'une mise à jour, la configuration d'authentification courante reste inchangée. Consultez la page InboundAuthConfig.
Si vous utilisez l'authentification de session du navigateur de domaine d'identité et que vous avez besoin d'un accès public uniquement pour les chemins sélectionnés, configurez les modèles de chemin d'accès public. Par exemple, vous pouvez autoriser l'accès à /assets/* tout en conservant la connexion à d'autres chemins. Voir Session du navigateur de domaine d'identité.
Authentification sortante
Avec l'authentification sortante, les applications d'agent déployées peuvent accéder en toute sécurité à d'autres ressources OCI dans une location.
L'accès est accordé en définissant des politiques OCI IAM qui autorisent l'application d'agent (en tant que principal de ressource) à effectuer des actions spécifiques sur les ressources spécifiées. Ces politiques déterminent la portée de l'accès en fonction du principe du moindre privilège.
Après le déploiement, la plate-forme provisionne automatiquement un jeton de session principal de ressource (RPST) pour la charge de travail de l'agent. Le RPST est injecté en toute sécurité dans l'exécution du conteneur, ce qui permet à l'application de s'authentifier auprès des services OCI sans utiliser de données d'identification de longue durée telles que des clés d'API ou des jetons d'utilisateur.
Dans le conteneur, l'agent utilise la trousse SDK OCI avec le fournisseur d'authentification du principal de ressource. La trousse SDK extrait et actualise automatiquement le RPST, ce qui permet un accès sécurisé aux services OCI autorisés tels que le service de stockage d'objets, la base de données d'IA autonome, la chambre forte et le service de diffusion en continu.