Les jetons d'accès Microsoft Azure Active Directory respectent la norme OAuth 2.0 avec des extensions.

Le jeton d'accès ID Entra sera nécessaire avant d'accéder à la base de données à partir du client de base de données (par exemple, avec SQLPlus ou SQLcl). Les clients Oracle (par exemple, OCI, JDBC et ODP) peuvent être configurés pour récupérer un jeton d'ID Entra à partir d'un emplacement de fichier ou le jeton peut être transmis au client via l'API du client de base de données. Un utilisateur Azure peut utiliser un script (exemples disponibles auprès de Microsoft) pour extraire un jeton et le placer dans un emplacement de fichier pour que le client de base de données puisse l'extraire. Les applications peuvent utiliser le kit SDK Azure pour obtenir un jeton d'accès et le transmettre via l'API client de base de données. Des outils de ligne de commande tels que Microsoft PowerShell ou l'interface de ligne de commande Azure peuvent être utilisés pour extraire le jeton d'ID Entra si l'application ne peut pas obtenir directement le jeton.

Le schéma suivant est un schéma de flux généralisé pour la norme OAuth 2.0, qui utilise le jeton OAuth2. Pour plus d'informations sur chaque flux pris en charge, reportez-vous à Prise en charge du flux d'authentification dans MSAL dans la documentation Microsoft Entra ID.

Description de l'image azure-authentication.eps

Le flux de code d'autorisation est une norme OAuth2 et est décrit en détail dans le cadre des normes. Il y a deux étapes dans le flux. La première étape authentifie l'utilisateur et extrait le code d'autorisation. La deuxième étape utilise le code d'autorisation pour obtenir le jeton d'accès à la base de données.

1. L'utilisateur Azure demande l'accès à la ressource, l'instance Oracle Database.
2. L'application ou le client de base de données demande un code d'autorisation à partir de l'ID Entra.
3. L'ID Entra authentifie l'utilisateur Azure et renvoie le code d'autorisation.
4. L'application ou l'outil d'aide utilise le code d'autorisation avec l'ID Entra pour l'échanger contre le jeton OAuth2.
5. Le client de base de données envoie le jeton d'accès OAuth2 à la base de données Oracle. Le jeton inclut les rôles d'application de base de données auxquels l'utilisateur a été affecté dans l'inscription de l'application Entra ID pour la base de données.
6. L'instance Oracle Database utilise la clé publique de l'ID Entra pour vérifier que le jeton d'accès a été créé par l'ID Entra.

Le client de base de données et le serveur de base de données doivent être inscrits auprès de la fonctionnalité Inscriptions des applications dans la section Azure Active Directory du portail Azure. Le client de base de données doit être inscrit auprès de l'enregistrement de l'application Entra ID. Un droit d'accès doit également être accordé pour permettre au client de base de données d'obtenir un jeton d'accès pour la base de données.

Les utilisateurs Microsoft Azure doivent être mis en correspondance avec un schéma Oracle Database et disposer des privilèges nécessaires (via des rôles) pour pouvoir s'authentifier auprès de l'instance Oracle Database.

Dans Microsoft Azure, un administrateur Entra ID peut affecter des utilisateurs, des groupes et des applications aux rôles d'application de base de données.

La mise en correspondance exclusive d'un utilisateur Entra ID avec un schéma de base de données nécessite que l'administrateur de base de données crée et gère un schéma de base de données pour le cycle de vie de l'utilisateur (jointure, déplacement, départ). L'administrateur de base de données doit créer le schéma lorsque l'utilisateur rejoint l'organisation. L'administrateur de base de données doit également modifier les privilèges et les rôles accordés au schéma de base de données pour les aligner sur les tâches auxquelles l'utilisateur Azure est affecté. Lorsque l'utilisateur Azure quitte l'organisation, l'administrateur de base de données doit supprimer le schéma de base de données afin qu'aucun compte inutilisé ne soit laissé sur la base de données. L'utilisation des rôles d'application de base de données permet à l'administrateur de l'ID Entra de contrôler l'accès et les rôles en affectant des utilisateurs à des rôles d'application qui sont mis en correspondance avec des schémas et rôles globaux. Ainsi, l'accès utilisateur à la base de données est géré par les administrateurs d'ID Entra et les administrateurs de base de données n'ont pas besoin de créer, de gérer et de supprimer des schémas pour chaque utilisateur.

Un utilisateur Azure peut être mis en correspondance avec un schéma de base de données (utilisateur) exclusivement ou via un rôle d'application.

• Création d'une mise en correspondance exclusive entre un utilisateur Azure et un schéma Oracle Database. Dans ce type de mapping, le schéma de base de données doit être créé pour l'utilisateur Azure. Les privilèges et rôles de base de données requis par l'utilisateur Azure doivent être accordés au schéma de base de données. Le schéma de base de données doit non seulement être créé lorsque l'utilisateur Azure est autorisé à accéder à la base de données, mais les privilèges et rôles accordés doivent également être modifiés lorsque les rôles et les tâches de l'ID Entra changent. Enfin, le schéma de base de données doit être supprimé lorsque l'utilisateur Azure quitte l'organisation.
• Créer une mise en correspondance partagée entre un rôle d'application Entra ID et un schéma Oracle Database. Ce type de mapping, plus commun que les mappings exclusifs, est destiné aux utilisateurs Azure auxquels le rôle d'application a été directement affecté ou qui sont membres d'un groupe d'ID Entra affecté au rôle d'application. Le rôle d'application est mis en correspondance avec un schéma Oracle Database (mise en correspondance de schéma partagée). La correspondance de schéma partagée permet à plusieurs utilisateurs Azure de partager le même schéma Oracle Database, de sorte qu'il n'est pas nécessaire de créer un schéma de base de données à chaque fois qu'un nouvel utilisateur rejoint l'organisation. Cette efficacité opérationnelle permet aux administrateurs de base de données de se concentrer sur les tâches liées à la maintenance, aux performances et au réglage de l'application de base de données au lieu d'avoir à configurer de nouveaux utilisateurs, à mettre à jour les privilèges et les rôles, et à enlever des comptes.

En plus des rôles de base de données et des privilèges accordés directement au schéma global mis en correspondance, des rôles et des privilèges supplémentaires peuvent être accordés via les rôles globaux mis en correspondance. Différents utilisateurs Azure mis en correspondance avec le même schéma global partagé peuvent avoir besoin de différents privilèges et rôles. Les rôles d'application Azure peuvent être mis en correspondance avec les rôles globaux Oracle Database. Le rôle global Oracle Database sera accordé aux utilisateurs Azure qui sont affectés au rôle d'application ou qui sont membres d'un groupe d'ID Entra affecté au rôle d'application lorsqu'ils accéderont à la base de données.

Le schéma suivant illustre les différents types d'affectation et de mise en correspondance disponibles.

Description de l'image azure_mappings.eps

Ces mises en correspondance sont les suivantes :

• Un utilisateur Azure peut être mis en correspondance directement avec un schéma global Oracle Database (utilisateur).
• Un rôle d'application est affecté à un utilisateur Azure, un groupe d'ID Entra ou une application, puis celui-ci est mis en correspondance avec un schéma global Oracle Database (utilisateur) ou un rôle global.

Oracle Database prend en charge plusieurs cas d'emploi pour la connexion à la base de données.

• Flux de code d'autorisation OAuth2 : il s'agit du flux le plus courant pour les utilisateurs humains. Le client dirige l'utilisateur Azure vers l'ID Entra pour obtenir le code d'autorisation. Ce code est utilisé pour obtenir le jeton d'accès à la base de données. Reportez-vous à l'article Microsoft Azure Plateforme d'identités Microsoft et flux de code d'autorisation OAuth.
• Informations d'identification de mot de passe de propriétaire de ressource : ce flux n'est pas recommandé pour les serveurs de production. Il est utile pour les logiciels de test qui ne peuvent pas fonctionner avec une fenêtre d'authentification instantanée. Il est utilisé dans les environnements d'interface utilisateur non graphiques lorsqu'une fenêtre instantanée ne peut pas être utilisée pour authentifier un utilisateur.
• Informations d'identification client : ce flux est utilisé pour permettre aux applications de se connecter à la base de données. L'application doit s'inscrire avec l'enregistrement de l'application Entra ID et a besoin d'un ID client et d'un mot de passe client. Ces informations d'identification client doivent être utilisées pour obtenir le jeton d'accès à la base de données à partir de l'ID Entra lorsque l'application se connecte à la base de données. L'application peut transmettre le jeton via le système de fichiers ou via l'API client de base de données.
• Jeton Au nom de : une application Azure demande un jeton Au nom de : pour un utilisateur connecté. Le jeton OBO sera également un jeton d'accès pour la base de données avec l'identité utilisateur Azure et les rôles d'application affectés de la base de données. L'utilisateur Azure peut ainsi se connecter à la base de données en tant qu'utilisateur et non en tant qu'application. Seule une application peut demander un jeton OBO pour son utilisateur Azure et le transmettre au client de base de données via l'API.