Documentation sur Oracle Cloud Infrastructure

Configuration d'une politique d'authentification unique

Créez une politique d'authentification pour chaque ressource que vous avez créée pour votre application d'entreprise.

Une politique d'authentification définit la méthode d'authentification à utiliser pour protéger les ressources de votre application d'entreprise, et détermine si la passerelle d'application ajoute des variables d'en-tête à la demande qu'elle transmet à l'application.
  1. Dans la page de liste Applications intégrées, sélectionnez l'application d'entreprise à modifier. Si vous avez besoin d'aide pour trouver la page de liste, voir Liste des applications.
  2. Dans la page Détails de l'application, sélectionnez Configuration de l'authentification unique, puis Modifier la configuration de l'authentification unique. Dans la section Politique d'authentification, sélectionnez Validation du public, Autoriser la spécification CORS ou Témoins sécurisés requis, si nécessaire.
    • Validation du public : pour des raisons de sécurité, assurez-vous que la case Validation du public est cochée. La case à cocher de validation du public est utilisée pour s'assurer que le jeton a été émis par l'émetteur connu de la passerelle d'application, dans ce cas IAM. Si vous désélectionnez la case de validation du public, la passerelle d'application ne valide pas le public du jeton, ce qui rend l'application vulnérable aux attaques.
    • Autoriser la spécification CORS: Sélectionnez cette option pour activer la spécification CORS afin que les applications qui s'exécutent sur un domaine d'identité puissent obtenir des données d'un autre domaine d'identité.
    • Témoins sécurisés requis : Si la passerelle d'application est configurée en mode SSL (HTTP), vérifiez que l'option Témoins sécurisés requis est sélectionnée. Cet indicateur définit l'en-tête sécurisé pour éviter l'utilisation de témoins dans une communication HTTP non sécurisée. Si la passerelle d'application est configurée en mode non SSL (HTTP), désélectionnez Témoins sécurisés requis.
  3. Cochez Ajouter des ressources gérées.
  4. Dans la fenêtre Ajouter une ressource gérée, sélectionnez la ressource pour laquelle vous voulez configurer une politique d'authentification dans la liste des ressources que vous avez créées dans la section Ressources ou ajoutez une ressource gérée.
  5. Utilisez le tableau suivant pour définir la méthode d'authentification pour la ressource sélectionnée :

    Méthode d'authentification

    Description

    Autorisation de base

    La méthode Authentification de base effectue l'authentification de base HTTP. Si la demande ne contient pas d'en-tête Authentification de base, le navigateur de l'utilisateur demande les données d'identification.

    Les données d'identification envoyées dans l'en-tête se trouvent dans les éléments AuthenticationBasic validés dans GIA.

    Auth+Logout de base

    Cette méthode est utilisée pour protéger la ressource (URL) de l'application qui représente le processus de déconnexion de l'application.

    Lorsque la passerelle d'application intercepte une demande à cette ressource, le processus de déconnexion HTTP est lancé. Ce processus supprime tout témoin de session HTTP créé par la méthode d'authentification Authentification de base+Session .

    Une fois le processus de déconnexion terminé, la passerelle d'application réachemine le navigateur de l'utilisateur vers la ressource de l'application demandée.

    Le processus de déconnexion HTTP n'efface pas les données d'identification mises en mémoire cache par le navigateur dans la session de navigateur courante. L'utilisateur peut ensuite ne pas être invité de nouveau à entrer des demandes ultérieures.

    Auth+Session de base

    Fonctionne de la même manière que l'authentification de base. Une fois les données d'identification validées, crée un témoin de session HTTP (ORA_OCIS_CG_BA_SESSION).

    Formulaire ou jeton d'accès

    Dans cette méthode d'authentification, la passerelle d'application délègue la collecte et la validation des données d'identification au service GIA.

    Si un en-tête Authorization Bearer est présent dans la demande, l'authentification est similaire à un flux de serveur de ressources. Si un en-tête user-agent est présent, un flux de navigateur d'utilisateur se produit.

    Le flux du navigateur de l'utilisateur redirige le navigateur de l'utilisateur vers GIA pour la collecte et la validation des données d'identification, puis crée un témoin de session OAuth (ORA_OCIS_CG_SESSION_*).

    Si un en-tête Authorization session est présent dans la demande et que le témoin de session OAuth est manquant ou non valide, le flux de connexion OAuth habituel est supprimé et un code d'erreur HTTP 401 est retourné avec un en-tête WWW-Authenticate: Bearer error="invalid_session". Cela est utilisé par les applications qui peuvent déclencher une connexion non voulue lorsque leurs demandes contiennent un en-tête user-agent, mais pas un en-tête Authorization Bearer, ce qui leur permet de gérer elles-mêmes la réauthentification.

    Form+Logout

    Cette méthode est utilisée pour protéger la ressource (URL) de l'application qui représente le processus de déconnexion de l'application.

    L'URL de cette ressource n'a pas besoin d'être exposée par l'application, car la passerelle d'application redirige le navigateur d'utilisateur vers le point d'extrémité de déconnexion GIA OAuth (/oauth2/v1/userlogout) au lieu de transmettre la demande à l'URL de l'application.

    Dans la fenêtre Ajouter une ressource, l'URL d'après connexion est l'URL vers laquelle la passerelle d'application redirige le navigateur de l'utilisateur après l'avoir déconnecté. Vous pouvez également fournir une valeur de paramètre État d'après connexion qui doit être utilisée par la page URL d'après connexion de l'application.

    Multitoken

    Exécute une authentification basée sur le contenu de l'en-tête Authorization de la demande :

    • Si la demande contient un en-tête Authorization Basic, la passerelle d'application traite cette authentification en tant qu'authentification de base.
    • Si la demande contient un en-tête Authorization Bearer ou Authorization Session, la passerelle d'application traite cette authentification en tant que Formulaire ou jeton d'accès.
    • Si l'en-tête d'autorisation est manquant ou a une autre valeur, une erreur HTTP 401 Unauthoized est retournée.

    Multitoken+Fallthrough

    Comme Multijeton, mais si l'en-tête Authorization n'est pas Basic, Bearer ou session, au lieu de présenter l'erreur HTTP 401 Unauthoized, la passerelle d'application de la demande agit comme si la méthode d'authentification était Authentification de base.

    Anonyme

    • Si un témoin de session OAuth valide est présent, les en-têtes configurés dans la politique d'authentification sont ajoutés à la demande et la demande est transmise à l'application.
    • Si le témoin de session OAuth est manquant ou expiré, fonctionne de la même manière que la méthode d'authentification Public. Dans ce cas, un en-tête REMOTE_USER avec la valeur anonymous est ajouté à la demande.

    Pour les deux options, les en-têtes configurés dans la politique d'authentification sont ajoutés à la demande, mais l'authentification n'est pas effectuée.

    Public

    Aucune authentification n'est effectuée. La demande est transmise à l'application telle quelle.

    Non prise en charge

    Cette méthode retourne toujours le code d'erreur HTTP 500 Not Supported.

    Par exemple, vous pouvez utiliser cette méthode pour désactiver l'accès à une URL protégée disponible dans l'application, mais vous ne voulez pas que les utilisateurs y accèdent.
  6. La méthode d'authentification que vous avez sélectionnée à l'étape précédente est valide pour toutes les méthodes HTTP (GET, HEAD, DELETE, PUT, OPTIONS, CONNECT, POST ou PATCH). Si vous voulez spécifier différentes méthodes d'authentification pour les méthodes HTTP (par exemple, la méthode d'authentification Format + Jeton d'accès pour la méthode HTTP GET et la méthode d'authentification Multijeton pour la méthode HTTP POST), vous pouvez le faire à l'aide du menu Remplacements de la méthode d'authentification. Sélectionnez la méthode HTTP, puis la méthode d'authentification souhaitée. Si vous devez remplacer plusieurs méthodes HTTP, répétez cette étape plusieurs fois.
  7. Si vous voulez ajouter une variable d'en-tête à la demande pour que la passerelle d'application la transmette à l'application, sélectionnez l'icône plus + pour En-têtes, indiquez le nom, puis sélectionnez la valeur de la variable d'en-tête dans la liste des attributs d'utilisateur, entrez une valeur fixe ou indiquez une expression. Pour ajouter plusieurs variables d'en-tête, sélectionnez plusieurs fois l'icône + pour En-têtes.

    Par exemple, supposons que l'application exige qu'une variable d'en-tête nommée USERLOGGEDIN soit présente dans chaque demande afin que l'application connaisse l'ID de l'utilisateur connecté au service GIA. Vous devez ajouter une variable d'en-tête, entrer USERLOGGEDIN dans le champ Nom, puis sélectionner Nom d'utilisateur dans la liste ou entrer $subject.user.userName pour Valeur.

    Note

    Vous pouvez sélectionner un attribut d'utilisateur dans le menu ou fournir une expression à l'aide de n'importe quel attribut du schéma d'utilisateur SCIM d'IAM en tant que valeur de variable d'en-tête. Voir Expressions de valeur d'en-tête prises en charge pour les politiques d'authentification.

  8. Sélectionnez Ajouter une ressource gérée.
  9. Sélectionnez enregistrer les modifications.