Microsoft Azure Active Directoryアクセス・トークンは、OAuth 2.0標準とその拡張に従います。

Entra IDアクセス・トークンは、データベース・クライアント(SQLPlusまたはSQLclなど)からデータベースにアクセスする前に必要です。Oracleクライアント(OCI、JDBC、ODPなど)がファイルの場所からEntra IDトークンを選択するように構成されるか、またはトークンがデータベース・クライアントAPIを介してクライアントに渡されます。Azureユーザーはスクリプト(例についてはMicrosoftを参照)を使用してトークンを取得し、それをデータベース・クライアントが取得できるファイルの場所に配置できます。アプリケーションは、Azure SDKを使用してアクセス・トークンを取得し、データベース・クライアントAPIを介して渡すことができます。アプリケーションが直接トークンを取得できない場合は、Microsoft PowerShellやAzureコマンドライン・インタフェースなどのコマンドライン・ツールを使用して、Entra IDトークンを取得できます。

次の図は、OAuth2トークンを使用したOAuth 2.0標準の一般的なフロー図です。サポートされている各フローの詳細は、Microsoft Entra IDドキュメントのMSALでの認証フローのサポートを参照してください。

図azure-authentication.epsの説明

認可コード・フローはOAuth2標準で、標準の一部として詳細に説明されています。フローには2つのステップがあります。最初のステップでは、ユーザーを認証し、認可コードを取得します。2番目のステップでは、認可コードを使用してデータベース・アクセス・トークンを取得します。

1. Azureユーザーは、リソース、Oracle Databaseインスタンスへのアクセスをリクエストします。
2. データベース・クライアントまたはアプリケーションは、Entra IDからの認可コードをリクエストします。
3. Entra IDはAzureユーザーを認証し、認可コードを返します。
4. ヘルパー・ツールまたはアプリケーションは、Entra IDの認可コードを使用して、それをOAuth2トークンと交換します。
5. データベース・クライアントは、OracleデータベースにOAuth2アクセス・トークンを送信します。トークンには、データベースのためのEntra IDアプリケーション登録でユーザーが割り当てられたデータベース・アプリケーション・ロールが含まれます。
6. Oracle Databaseインスタンスでは、Entra ID公開キーを使用して、アクセス・トークンがEntra IDによって作成されたことを確認します。

データベース・クライアントとデータベース・サーバーの両方を、Azureポータルの「Azure Active Directory」セクションのアプリケーション登録機能に登録する必要があります。データベース・クライアントは、Entra IDアプリケーション登録で登録する必要があります。データベース・クライアントには、データベースのアクセス・トークン取得を許可する権限も付与する必要があります。

Microsoft Azureユーザーは、Oracle Databaseインスタンスに対して認証できるようになる前に、Oracle Databaseスキーマにマップされ、(ロールを介して)必要な権限を持っている必要があります。

Microsoft Azureでは、Entra ID管理者は、ユーザー、グループおよびアプリケーションをデータベース・アプリケーション・ロールに割り当てることができます。

Entra IDユーザーをデータベース・スキーマに排他的にマッピングするには、データベース管理者がユーザーのライフサイクル(参加、移動、退去)のデータベース・スキーマを作成および管理する必要があります。データベース管理者は、ユーザーが組織に参加するときにスキーマを作成する必要があります。また、データベース管理者は、Azureユーザーが割り当てられているタスクに合わせて、データベース・スキーマに付与されている権限およびロールを変更する必要があります。Azureユーザーが組織を離れた場合、データベース管理者はデータベース・スキーマを削除して、使用されていないアカウントがデータベースに残らないようにする必要があります。データベース・アプリケーション・ロールを使用すると、Entra ID管理者は、グローバル・スキーマおよびグローバル・ロールにマップされているアプリケーション・ロールにユーザーを割り当てることによってアクセスおよびロールを制御できます。このようにして、データベースへのユーザー・アクセスはEntra ID管理者によって管理されるため、データベース管理者がすべてのユーザーのスキーマを作成、管理および削除する必要はありません。

Azureユーザーは、排他的に、またはアプリケーション・ロールを介してデータベース・スキーマ(ユーザー)にマップできます。

• AzureユーザーとOracle Databaseスキーマ間の排他的マッピングの作成。このタイプのマッピングでは、Azureユーザーに対してデータベース・スキーマを作成する必要があります。Azureユーザーが必要とするデータベース権限およびロールは、データベース・スキーマに付与する必要があります。データベース・スキーマは、Azureユーザーがデータベースに対して認可されたときに作成するだけでなく、付与された権限およびロールをEntra IDのロールおよびタスクの変更に応じて変更する必要があります。最後に、データベース・スキーマはAzureユーザーが組織を離れるときに削除する必要があります。
• Entra IDアプリケーション・ロールとOracle Databaseスキーマ間の共有マッピングの作成排他的マッピングよりも一般的なこのタイプのマッピングは、アプリケーション・ロールに直接割り当てられるAzureユーザーか、アプリケーション・ロールに割り当てられるEntra IDグループのメンバー用です。アプリケーション・ロールは、Oracle Databaseスキーマにマップされます(共有スキーマ・マッピング)。共有スキーマ・マッピングを使用すると、複数のAzureユーザーが同じOracle Databaseスキーマを共有できるため、新規ユーザーが組織に加入するたびに新しいデータベース・スキーマを作成する必要はありません。この運用上の効率により、データベース管理者は、新規ユーザーの構成、権限とロールの更新、およびアカウントの削除を行うことなく、データベース・アプリケーションのメンテナンス、パフォーマンスおよびチューニングのタスクに集中できます。

マップされたグローバル・スキーマに直接付与されているデータベース・ロールおよび権限に加えて、マップされたグローバル・ロールを介して追加のロールおよび権限を付与できます。同じ共有グローバル・スキーマにマップされた異なるAzureユーザーには、異なる権限およびロールが必要になる場合があります。Azureアプリケーション・ロールは、Oracle Databaseグローバル・ロールにマップできます。アプリケーション・ロールに割り当てられているか、アプリケーション・ロールに割り当てられているEntra IDグループのメンバーであるAzureユーザーには、データベースへのアクセス時にOracle Databaseグローバル・ロールが付与されます。

次の図は、使用できる様々なタイプの割当ておよびマッピングを示しています。

図azure_mappings.epsの説明

これらのマッピングは次のとおりです:

• Azureユーザーは、Oracle Databaseグローバル・スキーマ(ユーザー)に直接マップできます。
• Azureユーザー、Entra IDグループまたはアプリケーションがアプリケーション・ロールに割り当てられ、その後、Oracle Databaseグローバル・スキーマ(ユーザー)またはグローバル・ロールのいずれかにマップされます。

Oracle Databaseでは、データベースへの接続にいくつかのユースケースをサポートしています。

• OAuth2認可コード・フロー:人間のユーザーに対して最も一般的なフローです。クライアントは、認可コードを取得するために、AzureユーザーにEntra IDを指示します。このコードは、データベース・アクセス・トークンの取得に使用されます。Microsoft Azureの記事のMicrosoft IDプラットフォームとOAuth 2.0認可コード・フローを参照してください。
• リソース所有者のパスワード資格証明(ROPC): このフローは、本番サーバーではお薦めしません。ポップアップ認証ウィンドウでは動作しないテスト・ソフトウェアで使用できます。これは、非グラフィック・ユーザー・インタフェース環境でユーザーの認証にポップアップ・ウィンドウを使用できない場合に使用されます。
• クライアント資格証明: このフローは、アプリケーションのデータベースへの接続に使用されます。アプリケーションはEntra IDアプリの登録が必要で、クライアントIDとクライアント・パスワードが必要です。これらのクライアント資格証明は、アプリケーションがデータベースに接続するときのEntra IDからのデータベース・アクセス・トークン取得に使用する必要があります。アプリケーションは、ファイル・システムまたはデータベース・クライアントAPIを介してトークンを渡できます。
• On-Behalf-of (OBO)トークン: Azureアプリケーションは、ログイン・ユーザーのOBOトークンをリクエストします。OBOトークンは、Azureユーザー・アイデンティティを持つデータベースと、データベースに割り当てられたアプリケーション・ロールのアクセス・トークンでもあります。これにより、Azureユーザーは、アプリケーションではなくユーザーとしてデータベースにログインできます。アプリケーションのみが、AzureユーザーのOBOトークンをリクエストし、APIを介してデータベース・クライアントに渡すことができます。