8 Oracle DatabaseのMicrosoft Azureユーザーの認証および認可

Oracleデータベースは、Microsoft Entra ID (旧称Microsoft Azure AD)のMicrosoft Azureユーザーがシングル・サインオン認証を使用して接続するように構成できます。

ノート:

Microsoftは最近、Microsoft Azure ADの名前をMicrosoft Entra IDに変更しました。この名前の変更は、現在のOracle Databaseドキュメントで使用されています。以前のOracle Databaseリリースでは、Azure ADという名前が使用されていました。

8.1 Oracle DatabaseとMicrosoft Entra IDの統合の概要

OracleデータベースにアクセスするためのMicrosoft Entra IDの構成を開始する前に、全体的なプロセスについて理解する必要があります。

8.1.1 Oracle DatabaseとMicrosoft Entra IDの統合の概要

Oracle DatabaseおよびMicrosoft Entra IDは、ユーザーおよびアプリケーションがEntra ID資格証明を使用してデータベースに接続できるように構成できます。

Azureのユーザーおよびアプリケーションは、Entra IDシングル・サインオン(SSO)資格証明を使用してログインし、データベースにアクセスできます。これは、ユーザーまたはアプリケーションがEntra IDから最初にリクエストするEntra ID OAuth2アクセス・トークンを使用して行われます。このOAuth2アクセス・トークンには、ユーザーIDおよびデータベース・アクセス情報が含まれ、データベースに送信されます。マルチファクタ認証およびパスワードレス認証の構成の詳細は、Microsoft社の記事Azure Active Directoryのパスワードレス認証オプションを参照してください。

この統合は、次のOracle Database環境で実行できます。

  • オンプレミスOracle Databaseリリース19.18以降(21cを除く)
  • すべてのOracle Databaseサーバー・プラットフォーム: Linux、Windows、AIX、SolarisおよびHPUX
  • Oracle Autonomous Database Serverless
  • Oracle Autonomous Database on Dedicated Exadata Infrastructure
  • Oracle Autonomous Database on Exadata Cloud@Customer
  • Oracle Exadata Database Service on Dedicated Infrastructure
  • Oracle Exadata Database Service on Cloud@Customer
  • Oracle Base Database Service

Entra IDを構成する手順では、これらの環境を網羅するために「Oracle Database」という用語を使用します。

このタイプの統合により、AzureユーザーはOracle Databaseインスタンスにアクセスできます。Azureユーザーおよびアプリケーションは、Entra IDシングル・サインオン(SSO)資格証明を使用してログインし、データベースに送信するEntra ID OAuth2アクセス・トークンを取得できます。

Entra ID管理者は、Oracle Databaseを作成し、Entra IDに登録します。Entra ID内では、これはアプリ登録と呼ばれ、アプリケーション登録の略です。これは、Entra IDを使用しているソフトウェアについてEntra IDが知っておく必要があるデジタル情報です。Entra ID管理者は、Entra IDでのデータベース・アプリケーション登録用のアプリケーションのロールも作成します。アプリケーション・ロールは、Azureユーザー、グループおよびアプリケーションをデータベース・スキーマおよびロールに接続します。Entra ID管理者は、Azureユーザー、グループ、またはアプリケーションをアプリケーション・ロールに割り当てます。これらのアプリケーション・ロールは、データベース・グローバル・スキーマ、グローバル・ロール、またはスキーマとロールの両方にマップされます。アプリケーション・ロールに割り当てられたAzureユーザー、グループ、またはアプリケーションは、データベース・グローバル・スキーマ、グローバル・ロール、あるいはスキーマとロールの両方にマップされます。Oracleグローバル・スキーマは、Azureユーザーに排他的にマップすることもできます。Azureゲスト・ユーザー(非組織ユーザー)またはEntra IDサービス・プリンシパル(アプリケーション)は、Entra IDアプリケーション・ロールを介してのみデータベース・グローバル・スキーマにマップできます。Oracleグローバル・ロールはAzureアプリケーション・ロールからのみマップでき、Azureユーザーからはマップできません。

Entra IDトークンをサポートするために更新されるツールおよびアプリケーションは、Entra IDを使用してユーザーを直接認証し、データベース・アクセス・トークンをOracle Databaseインスタンスに渡すことができます。SQL*Plusなどの既存のデータベース・ツールを構成して、ファイルの場所からEntra IDトークンを使用できます。このような場合、Entra IDトークンは、Microsoft PowerShellやAzure CLIなどのツールを使用して取得し、ファイルの場所に配置できます。Entra ID OAuth2データベース・アクセス・トークンは、有効期限付きで発行されます。Oracle Databaseクライアント・ドライバは、トークンをデータベースに渡す前に、トークンの形式が有効であることと、有効期限が切れていないことを確認します。トークンのスコープはデータベースです。つまり、トークンにはそのトークンが使用されるデータベースに関する情報が含まれています。Entra IDプリンシパルがデータベースEntra IDアプリ登録で割り当てられたアプリケーション・ロールは、アクセス・トークンの一部として含まれています。Entra IDトークンのディレクトリの場所には、ユーザーがトークン・ファイルをその場所に書き込み、データベース・クライアントがこれらのファイルを取得するために十分な権限のみ(ユーザーによる読取りおよび書込みのみなど)を付与する必要があります。データベースへのアクセスはトークンによって許可されるため、トークンはファイル・システム内で保護される必要があります。

Azureユーザーは、いくつかの方法を使用してEntra IDからトークンをリクエストし、Azureログイン・ウィンドウを開いてEntra ID資格証明を入力できます。

Oracle Databaseは、次のEntra IDプリンシパルを表すトークンを受け入れます:

  • Azureユーザー。Entra IDテナンシの登録ユーザーです
  • ゲスト・ユーザー。Entra IDテナンシでゲスト・ユーザーとして登録されているユーザーです
  • サービス。クライアント資格証明フロー(接続プール・ユースケース)を使用し、それ自体としてデータベースに接続する登録済アプリケーションです

Oracle Databaseでは、次のEntra ID認証フローがサポートされています:

  • コード交換用証明キー(PKCE)を使用した対話型フロー(認可コード・フローとも呼ばれる)は、ブラウザを使用してクライアント環境でEntra IDに対して認証するために(アプリケーションではなく)人間のユーザーに最も一般的に使用されます
  • クライアント資格証明。(エンド・ユーザーとしてではなく)それ自体として接続するデータベース・アプリケーションで使用されます
  • On-Behalf-Of (OBO)。アプリケーションがログイン・ユーザーの代理としてアクセス・トークンを要求してデータベースに送信します
  • リソース所有者パスワード資格証明(ROPC)。本番環境での使用は推奨されませんが、ポップアップ・ブラウザでのユーザー認証の組込みが困難なテスト環境で使用できます。ROPCでは、トークン・リクエスト・コールの一部としてEntra IDユーザー名とパスワード資格証明が必要です。

ノート:

Microsoft Entra IDとのDBaaS統合では、管理権限(SYSDBASYSOPERSYSBACKUPSYSDGSYSKMおよびSYSRAC)を持つユーザーはサポートされていません。

8.1.2 Oracle DatabaseとMicrosoft Entra IDの統合のアーキテクチャ

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ドキュメントの『Authentication flow support in MSAL』を参照してください。

図8-1 対話型認可コード・フローを使用したAzureユーザーによるデータベースへのアクセス

図8-1の説明が続きます
「図8-1 対話型認可コード・フローを使用したAzureユーザーによるデータベースへのアクセス」の説明

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

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

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

8.1.3 Oracle DatabaseスキーマおよびロールのAzureユーザーのマッピング

Microsoft AzureユーザーをOracle Databaseインスタンスに対して認証するには、その前にMicrosoft Azureユーザーを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グローバル・ロールにマップできます。アプリケーション・ロールに割り当てられているAzureユーザーまたはアプリケーション・ロールに割り当てられているEntra IDグループのメンバーであるAzureユーザーには、データベースへのアクセス時にOracle Databaseグローバル・ロールが付与されます。

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

図8-2 Entra IDとOracle Databaseの間の割当てとマッピング

図8-2の説明が続きます
「図8-2 Entra IDとOracle Databaseの間の割当てとマッピング」の説明

これらのマッピングは、次のようになります。

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

8.1.4 Entra IDを使用したOracle Databaseへの接続のユースケース

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

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

8.1.5 Oracle DatabaseでMicrosoft Entra IDアイデンティティを認証する一般的なプロセス

Oracle Database管理者およびMicrosoft Entra ID管理者は、AzureユーザーがEntra ID OAuth2アクセス・トークンを使用してデータベースに接続できるようにするロールを果たします。

一般プロセスは次のとおりです。

  1. Oracle Database管理者は、Oracle Database環境がMicrosoft Entra ID統合の要件を満たしていることを確認します。「Microsoft Entra ID統合のためのOracle Databaseの要件」を参照してください。
  2. Entra ID管理者はデータベースのEntra IDアプリケーション登録を作成し、Oracle Database管理者はデータベース・アクセス用のEntra IDトークンを使用できるようにデータベースを有効にします。

    アプリケーション登録プロセスの一環として、Entra ID管理者は、Azureユーザー、グループおよびアプリケーションとOracle Databaseスキーマおよびロールの間のマッピングに使用するAzureアプリケーション・ロールを作成します。

  3. Oracle Database管理者は、グローバル・スキーマを作成して、Azureユーザー(排他的スキーマ・マッピング)またはAzureアプリケーション・ロール(共有スキーマ・マッピング)のいずれかにマップします。Azureユーザーまたはアプリケーションは、1つのスキーマにマップする必要があります。
  4. オプションで、Oracle管理者はグローバルOracle Databaseロールを作成し、Azureアプリケーション・ロールにマップします。
  5. Oracle Databaseインスタンスに接続するAzureエンド・ユーザーは、クライアント・アプリケーションをEntra IDクライアントとして登録します(Oracleデータベースを登録する方法と同様です)。

    アプリケーション・クライアントがパブリックでないかぎり、Entra IDクライアントにはクライアント識別およびクライアント・シークレットがあります。アプリケーション・クライアントがパブリックの場合は、アプリケーション・クライアント識別のみが必要です。

  6. Azureエンド・ユーザー(データベース管理者でもかまいません)は、PowerShellやAzureコマンドライン・インタフェースなどのユーティリティを使用して接続し、OAuth2データベース・アクセス・トークンを取得して、ローカル・ファイル・ディレクトリに格納します。また、アプリケーションは、Entra ID OAuth2アクセス・トークンをEntra IDから直接リクエストし、データベース・クライアントAPIを介して渡すこともできます。Entra ID OAuth2トークンの受渡しの詳細は、次のOracle Databaseクライアント・ドキュメントを参照してください:
  7. Oracle Databaseインスタンスに接続すると、Azureエンド・ユーザーは必要に応じてデータベース操作を実行します。

8.2 Microsoft Entra ID統合のためのOracle Databaseの構成

Microsoft Entra IDとOracle Databaseインスタンスを統合するには、データベースをEntra IDに登録する必要があります。

8.2.1 Microsoft Entra ID統合のためのOracle Databaseの要件

Microsoft Entra IDを使用してOracle Databaseインスタンスを構成するには、その前に環境が特別な要件を満たしていることを確認する必要があります。

オンプレミスの非クラウドOracleデータベースの場合は、このドキュメントのステップに従います。Oracleデータベースが次のいずれかのDBaaSプラットフォーム上にある場合は、追加の要件についてプラットフォームのドキュメントを参照してください。

次のことに注意してください。

  • Oracle Databaseサーバーは、Entra ID公開キーをリクエストできる必要があります。エンタープライズ・ネットワーク接続の設定によっては、プロキシ設定の構成が必要になる場合があります。
  • Entra IDトークンをリクエストする必要があるユーザーとアプリケーションは、Entra IDへのネットワーク接続も可能である必要があります。接続のプロキシ設定を構成する必要がある場合があります。
  • トークンを安全に転送するため、Oracle DatabaseクライアントとOracle Databaseサーバーの間にTransport Layer Security (TLS)を構成する必要があります。このTLS接続は、一方向または相互のいずれかです。
  • 自己署名または既知の認証局によって署名されるTLSサーバー証明書を作成できます。既知の認証局(CA)によって署名された証明書を使用する利点は、データベース・クライアントが、ルート証明書を使用してローカル・ウォレットを作成および保持するのではなく、システムのデフォルト証明書ストアを使用してOracle Databaseサーバー証明書を検証できることです。これはLinuxおよびWindowsクライアントにのみ適用されることに注意してください。

8.2.2 Oracle DatabaseインスタンスのMicrosoft Entra IDテナンシへの登録

Entra ID管理者権限を持つユーザーは、Microsoft Entra IDを使用して、Oracle DatabaseインスタンスをMicrosoft Entra IDテナンシに登録します。

  1. アプリケーションを登録するためのMicrosoft Entra ID権限を持つ管理者としてAzureポータルにログインします。
  2. 「Azure Active directory admin center」ページの左側のナビゲーション・バーで、「Azure Active Directory」を選択します。
  3. 「MS - App registrations」ページの左側のナビゲーション・バーで、「App registrations」を選択します。
  4. 「New registration」を選択します。
    「Register an application」ウィンドウが表示されます。azure-reg.pngの説明が続きます
    図azure-reg.pngの説明
  5. 「Register an application」ページで、次のOracle Databaseインスタンス登録情報を入力します。
    • 「Name」フィールドに、Oracle Databaseインスタンス接続の名前(Example Databaseなど)を入力します。
    • 「Supported account types」で、ユースケースに合ったアカウント・タイプを選択します。
      • Accounts in this organizational directory only (tenant_name only - Single tenant)
      • Accounts in any organizational directory (Any Entra ID directory - Multitenant)
      • Accounts in any organizational directory (Any Entra ID directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox)
      • Personal Microsoft accounts only
  6. 「Redirect URI」(オプション)設定は省略します。Entra IDにはデータベース・サーバー用のリダイレクトURIが不要なため、これを作成する必要はありません。
  7. 「Register」をクリックします。
    「Register」をクリックすると、Entra IDにアプリの登録の「Overview」ペインが表示され、「Essentials」の下にアプリケーション(クライアント) IDが表示されます。この値は、Microsoft IDプラットフォーム内のアプリケーションの一意の識別子です。アプリケーションという用語はOracle Databaseインスタンスを指します。
  8. データベース・アプリケーション登録のスコープを登録します。
    スコープとは、データベースにアクセスする権限です。各データベースには、データベース・スコープを使用する権限のリクエストによって、クライアントがデータベースとの信頼を確立できるようにするスコープが必要です。これにより、データベース・クライアントはデータベースのアクセス・トークンを取得できます。
    1. 左側のナビゲーション・バーで、「Expose an API」を選択します。
    2. 「Set the App ID URI」の下の「Application ID URI」フィールドに、次の書式を使用してデータベース接続のアプリケーションID URIを入力し、「Save」をクリックします。
      your_tenancy_url/application_(client)_id

      詳細は、次のとおりです。

      • your_tenancy_urlには、Entra IDテナンシの接頭辞および完全修飾ドメイン名としてhttpsを含める必要があります。
      • application_(client)_idは、Oracle DatabaseインスタンスをEntra IDに登録したときに生成されたIDです。これは、アプリの登録の「Overview」ペインに表示されます。

      たとえば:

      https://sales_west.example.com/1aa11111-1a1z-1a11-1a1a-11aa11a1aa1a
    3. 「Add a scope」を選択し、次の設定を入力します。
      azure-scope.pngの説明が続きます
      図azure-scope.pngの説明
      • 「Scope name」には、スコープの名前を指定します。次の名前を入力します。
        session:scope:connect

        この名前は任意のテキストにできます。ただし、スコープ名の入力は必須です。このスコープ名は、後でデータベース・クライアント・アプリケーションにデータベースへのアクセスを承認するときに使用することが必要になります。

      • 「Who can consent」には、必要な権限を指定します。「Admins and users」を選択するか、より制限を厳しくする場合は「Admins only」を選択します。
      • 「Admin consent」表示名には、管理者のみが表示できるスコープの目的(Connect to Oracleなど)を入力します。
      • 「Admin consent display name」には、管理者のみが表示できるスコープの目的(Connect to Example Databaseなど)を入力します。
      • 「User consent display name」は、スコープの目的の簡単な説明です(たとえば、Connect to Example Database)。これは、ユーザーが「Who can consent」「Admins and users」を指定した場合に表示されます。
      • 「User consent description」は、スコープの目的の詳細な説明です(たとえば、Connect to Example Database)。これは、ユーザーが「Who can consent」「Admins and users」を指定した場合に表示されます。
      • 「State」は、接続を有効または無効にします。「Enabled」を選択します。
これらのステップを完了すると、1つ以上のAzureアプリケーション・ロールを追加し、Oracleスキーマおよびロールのマッピングを実行する準備が整います。

8.2.3 Microsoft Entra ID v2アクセス・トークンの有効化

Oracle Databaseでは、v1およびv2 Azure AD OAuth2アクセス・トークンとの統合がサポートされています。

Oracle Databaseでは、Entra ID v2トークンとデフォルトのv1トークンがサポートされています。ただし、Entra ID v2トークンを使用するには、Oracle Databaseで機能すること確認するために追加のステップを実行する必要があります。このトークンは、アプリケーション登録エクスペリエンスを使用してAzureポータルに登録されているアプリケーションで使用できます。
Azure AD v2 OAuth2アクセス・トークンを使用すると、資格証明フローは変更なしで以前と同様に引き続き機能します。ただし、対話型フローでv2トークンを使用する場合は、upn:クレームを追加する必要があります。
  1. 使用しているEntra IDアクセス・トークンのバージョンを確認します。
  2. Microsoft Entra IDポータルにログインします。
  3. Entra IDを検索して選択します。
  4. 「Manage」で、「App registrations」を選択します。
  5. シナリオおよび目的の結果に基づいてオプションの要求を構成するアプリケーションを選択します。
  6. 「Manage」で、「Token configuration」を選択します。
  7. 「Add optional claim」をクリックし、「upn」を選択します。
v2トークンを使用すると、aud:クレームにはAPP ID値のみが反映されます。v2トークンが使用されている場合、https:domain接頭辞をAPP ID URIに設定する必要はありません。これにより、デフォルトのAPP ID URIを使用できるため、データベースの構成が簡略化されます。

8.2.4 Microsoft Entra IDでのアプリケーション・ロールの管理

Entra IDでは、Azureユーザーおよびグループに割り当てられ、Oracle Databaseのグローバル・スキーマおよびロールにもマップされるアプリケーション・ロールを作成および管理できます。

8.2.4.1 Microsoft Entra IDアプリケーション・ロールの作成

データベースに接続する必要のあるAzureユーザー、グループおよびアプリケーションは、データベース・アプリケーション・ロールに割り当てられます。

アプリケーション・ロールの作成方法の詳細は、Microsoft Azureの記事『Create and assign a custom role in Azure Active Directory』を参照してください。次のステップでは、Oracleデータベースで使用するアプリケーション・ロールを作成する方法について説明します。
  1. アプリケーション・ロールを作成する権限を持つ管理者としてEntra IDにログインします。
  2. 作成したOracle Databaseアプリ登録にアクセスします。
    1. 「Directory + subscription」フィルタを使用して、Oracle Databaseアプリ登録を含むEntra IDテナントを見つけます。
    2. 「Azure Active Directory」を選択します。
    3. 「Manage」で、「App registrations」を選択し、以前に登録したOracle Databaseインスタンスを選択します。
  3. 「Manage」で、「App roles」を選択します。
  4. 「App roles」ページで、「Create app role」を選択します。
  5. 「Create app role」ページで、次の情報を入力します。
    • 「Display name」は、ロールの表示名です(HR App Schemaなど)。この名前には空白を含めることができます。
    • 「Value」は、ロールの実際の名前です(HR_APPなど)。この設定は、スキーマまたはロールへのデータベース・マッピングで参照される文字列と正確に一致させます。この名前にはスペースを含めません。
    • 「Description」では、このロールの目的を説明します。
    • 「Do you want to enable this app role?」では、ロールをアクティブ化できます。
  6. 「適用」をクリックします。

    アプリのロールが「App roles」ペインに表示されます。

    azure-app-roles-creation.pngの説明が続きます
    図azure-app-roles-creation.pngの説明
8.2.4.2 Microsoft Entra IDアプリケーション・ロールへのユーザーおよびグループの割当て

Microsoft AzureユーザーがOracleデータベースにアクセスするためには、その前に、Oracle Databaseスキーマ・ユーザーまたはロールにマップされるアプリケーション・ロールにMicrosoft Azureユーザーを割り当てておく必要があります。

ユーザーおよびグループをアプリケーション・ロールに割り当てる手順の詳細は、Microsoft Azureの記事『Add app roles to your application and receive them in the token』を参照してください。次のステップでは、Oracleデータベース用にこれを実行する方法について説明します。
  1. AzureユーザーおよびEntra IDグループをアプリケーション・ロールに割り当てる権限を持つ管理者としてEntra IDにログインします。
  2. エンタープライズ・アプリケーションで、作成したOracle Databaseアプリケーション登録の名前を検索します。これは、アプリケーション登録の作成時に自動的に作成されます。
    1. 「Directory + subscription」フィルタを使用して、Oracle接続を含むAzure Active Directoryテナントを見つけます。
    2. 「Azure Active Directory」を選択します。
    3. 「Manage」で、「Enterprise applications」を選択し、以前に登録したOracle Databaseアプリケーション登録名を選択します。
  3. 「Getting Started」で「Assign users and groups」を選択します。
  4. 「Add user/group」を選択します。
  5. 「Add assignment」ウィンドウで、「Users and groups」を選択して、ユーザーおよびセキュリティ・グループのリストを表示します。
  6. このリストから、アプリケーション・ロールに割り当てるユーザーおよびグループを選択し、「Select」をクリックします。
  7. 「Add assignment」ウィンドウで、「Select a role」を選択して、作成したアプリケーション・ロールのリストを表示します。
  8. アプリケーション・ロールを選択し、「Select」を選択します。
  9. 「Assign」をクリックします。
8.2.4.3 アプリケーション・ロールへのアプリケーションの割当て

クライアント資格証明フローを使用してデータベースに接続する必要のあるアプリケーションは、アプリケーション・ロールに割り当てる必要があります。

  1. AzureユーザーおよびEntra IDグループをアプリケーション・ロールに割り当てる権限を持つ管理者としてEntra IDにログインします。
  2. アプリケーションのアプリ登録にアクセスします。
  3. 「Manage」で、「API permissions」を選択します。
  4. 「Configured permissions」領域で、「+ Add a permission」を選択します。
  5. 「Request API permission」ペインで、「My APIs」タブを選択します。
  6. このアプリケーションにアクセスを許可する対象のOracle Databaseアプリケーションを選択します。次に、「Application permissions」オプションを選択します。
  7. アプリケーションに割り当てるデータベース・アプリケーション・ロールを選択し、画面下部の「Add Permission」ボックスをクリックしてアプリケーション・ロールを割り当て、ダイアログ・ボックスを閉じます。割り当てたアプリケーション・ロールが「Configured permissions」の下に表示されることを確認します。
  8. 「Grant admin consent for tenancyを選択してテナンシ・ユーザーに承認を与え、確認ダイアログ・ボックスで「Yes」を選択します。

8.2.5 Oracle Databaseに対するEntra ID外部認証の有効化

Oracle DatabaseでのMicrosoft Entra ID外部認証を有効にする必要があります。

使用しているプラットフォームのEntra ID認証の詳細は、次のドキュメントのリンクを参照してください。
  1. ALTER SYSTEMシステム権限が付与されたユーザーとして、Oracle Databaseインスタンスにログインします。
  2. IDENTITY_PROVIDER_TYPEパラメータを次のように設定します。
    ALTER SYSTEM SET IDENTITY_PROVIDER_TYPE=AZURE_AD SCOPE=BOTH;
  3. IDENTITY_PROVIDER_TYPEパラメータが正しく設定されていることを確認します。
    SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME='identity_provider_type';

    次の出力が表示されます。

    NAME                    VALUE 
    ----------------------  ------- 
    identity_provider_type  AZURE_AD
  4. 次の構文を使用して、IDENTITY_PROVIDER_CONFIGパラメータを設定します。
    ALTER SYSTEM SET IDENTITY_PROVIDER_CONFIG =
    '{
       "application_id_uri": string , // from registered app, to be mapped in jwt "aud" claim;
                                     // Domain qualified to support cross tenancy resource access
       "tenant_id": string, // from tenant config
       "app_id": string // from registered resource app
    }' SCOPE=BOTH;

    たとえば:

    ALTER SYSTEM SET IDENTITY_PROVIDER_CONFIG =
    '{
      "application_id_uri" : "https://www.example.com/11aa1a11-aaaa-1111-1111-1111aa11111",
      "tenant_id" : "111a1111-a11a-111a-1a1a-1111111111a",
      "app_id" : "11aa1a11-aaaa-1111-1111-1111aa11111"
    }' SCOPE=BOTH;

Entra ID外部認証のためのOracle Databaseの有効化の詳細は、オンプレミス(非クラウド)のOracleデータベースに関してこのドキュメントで説明する情報に加え、次のプラットフォーム固有のドキュメントを参照してください。

8.2.6 Oracle Databaseに対するEntra ID外部認証の無効化

Oracle DatabaseインスタンスのEntra ID外部認証を無効にするには、ALTER SYSTEM文を使用する必要があります。

Oracle Databaseに加えて、この手順はOracle Autonomous Database on Dedicated Exadata InfrastructureおよびOracle Exadata Cloud Service (Oracle ExaCS)にも使用できます。これらの製品でEntra ID外部認証を無効にする場合は、製品ドキュメントを参照してください。

Oracle Autonomous Database ServerlessからEntra IDを無効にするには、「Oracle Autonomous Database Serverlessの使用」を参照してください。次の手順は、他のすべてのプラットフォームに適用されます。

  1. ALTER SYSTEMシステム権限が付与されたユーザーとして、Oracle Databaseインスタンスにログインします。
  2. アイデンティティ・プロバイダのパラメータを次のように設定します。
    ALTER SYSTEM RESET IDENTITY_PROVIDER_CONFIG SCOPE=BOTH;
    ALTER SYSTEM RESET IDENTITY_PROVIDER_TYPE SCOPE=BOTH;

8.3 Oracle Databaseスキーマおよびロールのマッピング

Azureユーザーは、1つのデータベース・スキーマにマップされ、オプションで1つ以上のデータベース・ロールにマップされます。

8.3.1 Oracle DatabaseスキーマのMicrosoft Azureユーザーへの排他的マッピング

Oracle DatabaseスキーマをMicrosoft Azureユーザーに排他的にマップできます。

  1. CREATE USERまたはALTER USERシステム権限を付与されたユーザーとして、Oracle Databaseインスタンスにログインします。
  2. Azureユーザー名を指定するIDENTIFIED GLOBALLY AS句を使用してCREATE USERまたはALTER USER文を実行します。
    たとえば、peter_fitchという名前の新しいデータベース・スキーマ・ユーザーを作成し、このユーザーをpeter.fitch@example.comという名前の既存のAzureユーザーにマップするには、次のようにします:
    CREATE USER peter_fitch IDENTIFIED GLOBALLY AS 
    'AZURE_USER=peter.fitch@example.com';
  3. CREATE SESSION権限をユーザーに付与します。
    GRANT CREATE SESSION TO peter_fitch;

8.3.2 共有Oracleスキーマのアプリケーション・ロールへのマッピング

このマッピングでは、Oracleスキーマがアプリケーション・ロールにマップされます。したがって、そのアプリケーション・ロールを持つすべてのユーザーが同じ共有スキーマを取得します。

  1. CREATE USERまたはALTER USERシステム権限を持つユーザーとして、Oracle Databaseインスタンスにログインします。
  2. Azureアプリケーション・ロール名を指定するIDENTIFIED GLOBALLY AS句を使用してCREATE USERまたはALTER USER文を実行します。
    たとえば、dba_azureという名前の新しいデータベース・グローバル・ユーザー・アカウント(スキーマ)を作成し、それをAZURE_DBAという名前の既存のEntra IDアプリケーション・ロールにマップするには、次のようにします:
    CREATE USER dba_azure IDENTIFIED GLOBALLY AS 'AZURE_ROLE=AZURE_DBA';

8.3.3 アプリケーション・ロールへのOracle Databaseグローバル・ロールのマッピング

Entra IDアプリにマップされたOracle Databaseグローバル・ロールは、Azureユーザーおよびアプリケーションに、ログイン・スキーマを介して付与されている権限およびロールに加え、さらに権限およびロールを付与します。

  1. CREATE ROLEまたはALTER ROLEシステム権限が付与されたユーザーとして、Oracle Databaseインスタンスにログインします
  2. Entra IDアプリケーション・ロールの名前を指定するIDENTIFIED GLOBALLY AS句を使用してCREATE ROLEまたはALTER ROLE文を実行します。
    たとえば、widget_sales_roleという名前の新しいデータベース・グローバル・ロールを作成し、それをWidgetManagerGroupという名前の既存のEntra IDアプリケーション・ロールにマップするには、次のようにします:
    CREATE ROLE widget_sales_role IDENTIFIED GLOBALLY AS 
    'AZURE_ROLE=WidgetManagerGroup';

8.4 Oracle DatabaseへのEntra IDクライアント接続の構成

登録済データベースに接続するようにクライアント接続を構成できます。

8.4.1 Entra IDへのクライアント接続の構成について

Oracle DatabaseクライアントがEntra ID OAuth2トークンを使用してアクセスのためにデータベースに送信するために、3つの異なる方法が用意されています。

  • Entra IDエンドポイントに直接接続し、ユーザーのトークンを取得します(対話型フロー)。

  • ファイルの場所からトークンを取得します(サポートされているすべてのEntra IDフロー)。

  • クライアントAPIを使用して、トークンをクライアントに渡します(サポートされているすべてのEntra IDフロー)。

Oracle Databaseでは、様々なユース・ケースに対して複数のEntra IDフローがサポートされています。各フローの詳細は、Microsoftのドキュメントで確認する必要があります。各データベース・クライアントは、異なるバージョンを持つ異なるフローをサポートできます。これらのタイプの詳細は、JDBC、ODP.NET、およびクライアントでサポートされているEntra IDフローに関するその他のプラットフォーム固有のクライアント・ドキュメントで確認できます。この項では、シック・クライアントとも呼ばれるOCIおよびインスタント・クライアントの使用について説明します。

使用可能なフローのタイプは次のとおりです:

  • 対話型フロー(OAuth2認証フローとも呼ばれる)は、人間のアクターが使用する主要なフローです。このフローでは、ユーザーがEntra ID資格証明を入力するためにブラウザを開くことができる環境が必要です。

  • デバイス・コード・フローは一部のクライアントでサポートされていますが、現在、OCIおよびInstant Clientではサポートされていません。このタイプのフローは、人間のアクター用でもあり、ブラウザを開けない環境用でもあります。

  • 管理対象アイデンティティ・フロー(一部のクライアントではサポートされますが、OCIおよびインスタント・クライアントではサポートされません)は、Azureコンピュート・ノードで実行され、ノードの管理対象アイデンティティにアクセスできるアプリケーション用です。

  • クライアント資格証明フローは、特にAzure環境で実行されていない場合に、アプリケーション用として設計されています。

  • リソース所有者のパスワード資格証明(ROPC)フローは、本番用途ではお薦めしません。

ユーザーが人間のアクターとしてデータベースにアクセスする必要がある場合、対話型フローを構成し、Entra IDからトークンを直接取得するようにデータベース・クライアントを構成することをお薦めします。アプリケーションは、クライアント資格証明フローを使用する必要があります。通常、アプリケーションは、定期的に実行されるスクリプトを使用してEntra IDからトークンを取得し、データベース・クライアントが使用できるようにファイルの場所に配置します。アプリケーションを変更してEntra ID SDKと統合できる場合は、SDKを使用してトークンを取得し、クライアントAPIを使用してクライアントに渡すこともできます。

ユースケースに最も適したクライアント接続方法を選択する必要があります。このガイドでは、Entra ID OAuth2アクセス・トークンを取得する様々な方法を使用してSQL*Plusを接続する例を紹介します。すべてのOracle Databaseリリース19cクライアントで、ファイルとして渡されるトークン、またはクライアントAPIを介して渡されるトークンを受け入れることができます。JDBC Thin、Instant ClientおよびODP.netドライバは、データベース・クライアントAPIを介してアプリケーションからのトークンも受け入れます。PowerShellやAzure CLIなどのツールは、クライアント・ドライバで使用するためにEntra ID OAuth2アクセス・トークンを取得できます。Entra IDトークンを取得するには、Entra IDアプリケーション登録プロセスを通じてクライアントを登録する必要があります。このクライアントの登録は、アプリケーション登録を使用したOracle DatabaseサーバーのEntra IDへの登録と同様に行われます。データベースとクライアントの両方をEntra IDに登録する必要があります。

データベースを登録する必要があるのは、クライアントがデータベースのアクセス・トークンを取得する権限を取得できるようにするためです。クライアントを登録する必要があるのは、Entra IDが信頼できるクライアントがアクセス・トークンをリクエストしていることを認識できるようにするためです。

クライアントをEntra IDに接続する方法の詳細は、次のMicrosoft Azureの記事を参照してください:

8.4.2 Microsoft Entra ID OAuth2トークンを使用したOracle DatabaseへのSQL*Plusクライアント接続の操作フロー

Azureユーザー、Entra IDおよびOracleデータベースの間の接続では、3つのコンポーネントを通じたOAuth2トークンの受渡しが利用されます。

Oracle DatabaseクライアントがEntra ID OAuth2トークンをOracleデータベースに送信するには、3つの方法があります。

  • Oracle Databaseクライアント経由
  • ファイルの場所の指定
  • Oracle DatabaseクライアントAPIの使用

Oracle Databaseクライアントを使用したOracle DatabaseへのEntra ID OAuth2トークンの送信

Oracle Databaseクライアントは、Entra IDエンドポイントからOAuth2トークンを直接リクエストできます。この方法により、必要な構成が簡略化されます。次の図は、パブリック・クライアントでの対話型フローの使用を示しています。対話型フローは、OAuth2認可フローとも呼ばれます。認可フローの詳細は、MicrosoftのMicrosoft identity platform and OAuth2.0 authorization code flow』に関する記事を参照してください。

図8-3 クライアントを使用してOracle Databaseに送信されるEntra ID OAuth2トークン

図8-3の説明が続きます
「図8-3 クライアントを使用してOracle Databaseに送信されるEntra ID OAuth2トークン」の説明
  1. ユーザーは、/スラッシュ・ログインを使用してAzure SSOログインを使用します。接続文字列(またはsqlnet.ora)には、Oracle Databaseクライアントがユーザーのトークンを取得するために必要なすべてのパラメータが含まれます。
  2. Oracle Databaseクライアントは、Entra IDエンドポイントに接続して認可コードをリクエストします。
  3. ユーザーがEntra IDを使用してログインしていない場合は、ブラウザ・ウィンドウが開き、ユーザーはAzure SSO資格証明を入力するようリクエストされます。
  4. Oracle Databaseクライアントは、認可コードを使用してOAuth2アクセス・トークンをリクエストします。
  5. Oracle Databaseクライアントは、OAuth2アクセス・トークンを受信すると、このトークンをOracleデータベースに送信します。
  6. Oracleデータベースは、(Entra ID公開キーを使用して)このアクセス・トークンがEntra IDからのものであることを確認してから、トークンに追加のクレームがないかどうかチェックします。次に、データベースはスキーマ・マッピング(排他的または共有)を検出し、セッションを作成します。データベースは、Azureユーザーにアプリケーション・ロールによっても割り当てられている、すべてのグローバル・ロールも付与します。

Oracle DatabaseにEntra ID OAuth2トークンを送信するためのファイルの場所の指定

次の図は、Entra ID OAuth2トークンをOracleデータベースに送信するためにファイルの場所を使用する方法を示しています。

図8-4 ファイルの場所を使用してOracle Databaseに送信されるEntra ID OAuth2トークン

図8-4の説明が続きます
「図8-4 ファイルの場所を使用してOracle Databaseに送信されるEntra ID OAuth2トークン」の説明
  1. Azureユーザーがスクリプトを使用してデータベースのEntra IDアクセス・トークンをリクエストし、返されたトークンが、特定のファイルの場所でtokenというファイルに書き込まれます。Azureユーザーは、この時点でEntra IDを使用して認証することがリクエストされる場合があります。
  2. Azureユーザーは、 /スラッシュ・ログインを使用してデータベースに接続します。sqlnet.oraまたはtnsnames.oraのいずれかの接続文字列により、Oracle Instant Clientは、Entra ID OAuth2トークンが必要であることを伝えられ、指定されたファイルの場所からこのトークンを取得するよう指示されます。その後、アクセス・トークンがOracleデータベースに送信されます。
  3. Oracleデータベースは、(Entra ID公開キーを使用して)このアクセス・トークンがEntra IDからのものであることを確認してから、トークンに追加のクレームがないかどうかチェックします。次に、データベースがスキーマ・マッピング(排他的または共有)を検出し、データベース・セッションを作成します。データベースは、Azureユーザーにアプリケーション・ロールによっても割り当てられている、すべてのグローバル・ロールも付与します。

Oracle DatabaseクライアントAPIを使用したOracle DatabaseへのEntra ID OAuth2トークンの送信

次の図は、Oracle DatabaseクライアントAPIを使用してEntra ID OAuth2トークンをOracleデータベースに送信する方法を示しています。

図8-5 クライアントAPIを使用してOracle Databaseに送信されるEntra ID OAuth2トークン

例8-5の説明が続きます
「図8-5 クライアントAPIを使用してOracle Databaseに送信されるEntra ID OAuth2トークン」の説明
  1. アプリケーションは、スクリプトを使用してOracleデータベースのEntra IDアクセス・トークンをリクエストします。返されたトークンは、クライアントAPIを使用してデータベース・クライアントに送信されます。トークンは、ユーザー(On-Behalf-Ofトークン・フロー)またはアプリケーション(クライアント資格証明フロー)を表すことができます
  2. Oracle Databaseクライアントは、アクセス・トークンをOracleデータベースに送信します。
  3. Oracleデータベースは、(Entra ID公開キーを使用して)このアクセス・トークンがEntra IDからのものであることを確認してから、トークンに追加のクレームがないかどうかチェックします。データベースがスキーマ・マッピング(排他的または共有)を検出し、セッションを作成します。データベースは、アプリケーション・ロールを介してアプリケーションまたはユーザーに割り当てられている任意のグローバル・ロールも付与します。

8.4.3 Entra ID接続でサポートされているクライアント・ドライバ

Oracle Databaseは、Entra ID接続用の複数のタイプのクライアント・ドライバをサポートしています。

四半期ごとのリリースで拡張機能が追加されるため、サポートされているバージョンには最新の四半期ごとのパッチを使用することをお薦めします。また、一部の機能はOracle Database 23aiバージョンにのみ存在し、バックポートされません。

  • シック・クライアント(OCI Cドライバ、Oracle Instant Client、Oracle Data Provider - 非管理(ODP.NET Unmanaged)、JDBC Thick、OCI Cドライバに基づくその他のクライアント): Oracle Database 19.16 (2022年7月)以上、21cではサポート対象外、Database 23aiでは完全サポート対象
  • JDBC Thin: Oracle Database 19.16 (2022年7月)、Oracle Database 21.8 (2022年10月)
  • Oracle Data Provider (ODP.NET Core、Managed): Oracle Database 19.16、Oracle Database 21.7
  • Python Thin: 1.1.0以上
  • Node.js Thin: v6.3以上

8.4.4 Entra IDアプリケーション登録によるクライアントの登録

このタイプの登録は、Entra IDアプリケーション登録によるOracle Databaseの登録と同様に行われます。

8.4.4.1 機密およびパブリック・クライアント登録

ユースケースに応じて、データベース・クライアントを機密またはパブリックとしてEntra IDに登録できます。

認証フローおよびアプリケーション・シナリオの詳細は、Microsoft Azureの記事『Authentication flows and application scenarios』を参照してください。

機密クライアント・アプリケーションを登録する場合、クライアントにはクライアントIDに加えてシークレットが必要です。機密クライアント・アプリケーションは、Entra IDリクエストを行うときにクライアントIDとシークレットの両方を使用します。ただし、企業においてSQL*PlusおよびSQLclのすべてのユーザーが独自のシークレットを持つ個別のアプリ登録を作成することは実用的ではありません。また、組織内でシークレットを共有し始めると、シークレットはもはやシークレットではなくなります。パブリック・クライアント・アプリケーションのみを作成するほうがはるかに有用です。パブリック・クライアント・アプリケーションはシークレットを持たず、クライアントIDのみを持ちます。すべてのデータベース・ツール・ユーザーは、Entra IDに接続するときにパブリック・クライアントIDを使用して、アクセス・トークンを取得できます。その場合もAzureユーザーは、自分のユーザー資格証明を使用してEntra IDに対して認証される必要があります。

8.4.4.2 Entra IDへのデータベース・クライアント・アプリケーションの登録

クライアント・アプリ登録の作成は、Microsoft Entra IDテナンシを使用してOracle Databaseインスタンスを作成する場合と同様に行われます。

  1. アプリケーションを登録するためのMicrosoft Entra ID権限を持つ管理者としてAzureポータルにログインします。
  2. 「Azure Active directory admin center」ページの左側のナビゲーション・バーで、「Microsoft Entra ID」を選択します。
  3. 「MS - App registrations」ページの左側のナビゲーション・バーで、「App registrations」を選択します。
  4. 「New registration」を選択します。
  5. 「Register an application」ページで、次のOracle Databaseクライアント登録情報を入力します:
    • 「Name」フィールドに、クライアント・アプリケーションの名前(DatabaseClientApplicationなど)を入力します。
    • 「Supported account types」で、ユースケースに合ったアカウント・タイプを選択します。
      • Accounts in this organizational directory only (tenant_name only - Single tenant)
      • Accounts in any organizational directory (Any Entra ID directory - Multitenant)
      • Accounts in any organizational directory (Any Entra ID directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox)
      • Personal Microsoft accounts only
  6. 「Redirect URI」(オプション)で、クライアント・アプリケーションのリダイレクトURIを構成します。
    azure-redirect-uri.pngの説明が続きます
    図azure-redirect-uri.pngの説明
    • 「Public client/native (mobile & desktop)」「Web」または「Single-page application (SPA)」を選択します。SQL*Plusを使用してOracle Databaseインスタンスにアクセスする必要があるデータベース管理者など、複数のユーザーがこのクライアント・アプリケーションを使用する場合は、「Public client」を選択します。
    • 別のアドレスを使用する場合を除き、リダイレクトURIとしてhttp://localhostを追加します。このリダイレクトURIは、認可フローで必要です。
  7. 「Register」をクリックします。
    これで、データベース・クライアントはEntra IDに登録されました。次は、Oracle Databaseインスタンスの認可クライアント・アプリケーションのリストに新しいクライアントを追加する必要があります。
  8. このクライアント・アプリケーションのリストに新しいクライアントを追加するには、次の手順を実行します。
    1. 新しいクライアントのアプリケーション(クライアント) IDをメモします。このIDはアプリケーションの「Overview」ページにあります。
    2. 「App registrations」ページで、メニューからデータベース・サーバーを選択して、そのアプリの登録ページを開きます。
    3. 左側で、「Expose an API」を選択します。
    4. 「Authorized client applications」が表示されるまで、メイン・ページを下にスクロールします。
    5. 「+」を選択して、クライアント・アプリケーションを追加します。
    6. 新しいクライアントのアプリケーション(クライアント) IDを「Client Id」フィールドにコピーします。
    7. 「Add application」をクリックします。

8.4.5 Microsoft Entra IDトークンを使用するためのクライアントの構成

Oracle Databaseクライアントに応じて、Entra IDからトークンを直接リクエストするか、ファイルの場所から取得するようにクライアントを構成できます。

8.4.5.1 Microsoft Entra IDトークンを使用するためのクライアントの構成

Entra ID OAuth2アクセス・トークンを使用するようにデータベース・クライアントを構成するために、様々な方法があります。

ユースケース(フロー)に応じて、データベース・クライアントはEntra IDエンドポイントからOAuth2トークンを直接リクエストできます。また、データベース・クライアントで使用するためにトークンを取得してファイルの場所に配置するには、別のユーティリティを実行する必要があります。アプリケーションは、Azure SDKを使用してトークンを取得し、データベース・クライアントAPIを介してこれを送信することもできます。クライアントAPIの使用およびクライアント構成情報については、データベース・クライアント固有のドキュメントを参照してください。Entra IDからトークンをリクエストする前に、次の構成を実行する必要があります。
  1. Azureユーザー・アカウントを持っていることを確認します。
  2. 次のいずれかについて、Entra ID管理者またはOracle Database管理者に確認します:
    • Entra IDトークンの取得に使用できるアプリケーション・クライアントID。これを行うためのEntra ID権限がある場合は、Oracle DatabaseインスタンスをEntra IDテナンシに登録するのと同様に、独自のクライアント・アプリケーション登録を作成します。
    • 直接またはアプリケーション・ロールを介して、データベース内のグローバル・スキーマにマップされます。
  3. Oracle Databaseクライアント・リリース19cまたは23ai以降の最新リリース更新を使用していることを確認してください。
    Entra IDの統合は、Oracle Database 21cではサポートされていません。
OAuth2トークンを渡すには、データベース・クライアントとデータベース・サーバーの間のTLS接続が必要です。TLS (サーバー認証)またはmTLS (クライアントおよびサーバー認証)を使用できます。データベース・クライアントおよびプラットフォームでサポートされている場合は、TLSを使用してウォレットを使用しない場合に単純にシステムのデフォルトの証明書ストアを使用できます。TLSの使用に加えて、部分DN一致または完全DN一致(SSL_SERVER_DN_MATCH = ON)を指定する必要があります。
8.4.5.2 クライアントによるEntra IDトークンの直接取得の有効化

クライアント自身がEntra IDトークンを直接取得できるようにパラメータを設定できます。

Oracle Databaseクライアントは、サポートしているフローに関してプラットフォームおよびバージョンによって異なります。次の表に、各クライアントがサポートできる内容を示します。

表8-1 トークンを直接取得するパラメータ

データベース・クライアント クライアントAPIを使用した受渡し ファイルの場所の使用 データベース・クライアントの直接サポート

シック・クライアント(OCI Cドライバ、インスタンス・クライアントとシック・クライアントを使用するプラットフォーム固有のドライバ(JDBC Thick、ODP.NET Unmanaged、Python Thickなど))

クライアント・バージョン19.16以上、21c以外、すべての23ai

すべてのフロー(対話型、クライアント資格証明、OBO、ROPC)でサポート対象

クライアント・バージョン19.16以上、21c以外、すべての23ai

すべてのフロー(対話型、クライアント資格証明、OBO、ROPC)でサポート対象

クライアント・バージョン23.4以上

対話型フローのサポートのみ

JDBC Thin

クライアント・バージョン19.16以上、21.7以上、すべての23ai

すべてのフロー(対話型、クライアント資格証明、OBO、ROPC)でサポート対象

クライアント・バージョン19.16以上、21.7以上、すべての23ai

すべてのフロー(対話型、クライアント資格証明、OBO、ROPC)でサポート対象

クライアント・バージョン23ai

次のフローをサポート(対話型、デバイス・コード、クライアント資格証明、管理対象アイデンティティ、OBO、ROPC)

ODP.NET Core、Managed

クライアント・バージョン19.16以上、21.7以上、すべての23ai

すべてのフロー(対話型、クライアント資格証明、OBO、ROPC)でサポート対象

クライアント・バージョン19.16以上、21.7以上、すべての23ai

すべてのフロー(対話型、クライアント資格証明、OBO、ROPC)でサポート対象

クライアント・バージョン23ai

次のフローをサポート(対話型、デバイス・コード、クライアント資格証明、管理対象アイデンティティ、OBO、ROPC)

Python Thin

サポート対象外

サポート対象外

サポート対象外

Node.js

サポート対象外

サポート対象外

サポート対象外

接続文字列パラメータは、データベース・クライアント間で共通です。これらのドライバを使用したこの機能に関するより具体的な詳細は、各データベース・クライアント・ドキュメント(JDBC Thin、ODP.NET Core、Managed)を参照してください。次の情報は、OCIシック・クライアント/インスタント・クライアント専用です。ただし、接続文字列パラメータに関する情報は、ドライバ全体で一貫性が保たれます。

クライアントでこの機能を有効にして、サポートされているフローについてEntra IDからトークンを直接取得するには、クライアントのsqlnet.oraファイルまたは接続文字列で次のパラメータを設定する必要があります。接続文字列はsqlnet.oraよりも優先されます。

データベース・クライアントがEntra ID OAuth2トークンを取得するには、データベース・クライアントがEntra IDエンドポイントに接続できる必要があります。ファイアウォールの背後で作業している場合は、インターネットに到達するためにプロキシの設定が必要になることがあります。インターネットに接続できるかどうかわからない場合は、「Microsoft Entra ID接続のトラブルシューティング」の項を参照してください。

表8-2 トークンを直接取得するパラメータ

パラメータ 説明

TOKEN_AUTH

トークン認証を設定します。データベース・クライアントにデータベース・トークンの取得またはファイルの場所からの取得を依頼する場合、このパラメータが必須です。クライアントAPIを介してトークンを渡す場合、このパラメータは必要ありません。

次のいずれかの値を入力します。

  • AZURE_INTERACTIVEは、データベースのアクセス・トークンを取得するためにEntra OAuth2対話型(OAuth2認可)フローを使用する必要があることをドライバに伝えます。これにより、外部スクリプトを使用する必要なく、Entra IDからトークンを直接取得するようにデータベース・クライアントが構成されます。これは、SQLclなどのツールにログインし、各自の環境でブラウザ・ウィンドウを開いて認証を行うことができる人間のユーザー向けです
  • AZURE_DEVICE_CODEは、Entra IDアクセス・トークンをリクエストするためのデバイス・コード・フローに従うようにデータベース・ドライバに通知します。これは、環境がブラウザを開けない場合(コマンドラインのみの環境)に、人間のユーザーにも使用されます。デバイスコードとEntra IDログインURLがツールの標準出力に書き込まれ、ユーザーは携帯電話やラップトップでEntra IDにログインし、デバイスコードを入力します。ユーザーは別のチャネルを介して認証され、認証が成功した場合は引き続きデータベースにアクセスできます。
  • AZURE_MANAGED_IDENTITYを使用すると、ドライバは、ホスト・システムに割り当てられている識別情報として認証できます。ホスト・システムは、仮想マシンなどのEntra IDによって管理されるリソースである必要があります。
  • AZURE_SERVICE_PRINCIPALを使用すると、ドライバは登録済アプリケーションのシークレットまたは証明書を使用して認証できます。

CLIENT_ID

アプリケーションが登録されたときにEntra IDによってアプリケーションに割り当てられた、一意のアプリケーション(クライアント) ID。このアプリケーションは、ユーザーのためにデータベースのアクセス・トークン取得をリクエストするデータベース・クライアントです。これは、データベース・サーバーのクライアントIDではありません。

AZURE_DB_APP_ID_URI

アプリケーションID URIは、Entra ID内のデータベースを一意に識別するURIです。この値は、データベースのEntra IDアプリケーション登録の概要画面から取得します。

TENANT_ID

データベースのAzureテナンシIDを指定します。

REDIRECT_URI

HTTPサーバーのポート番号を設定するためのオプションのパラメータ。このURLは、Entra認証エンドポイントから認可コードを取得し、認可コードを受信するために使用するポートを決定します。REDIRECT_URIが設定されていない場合、デフォルト値はhttp://localhost:8400です。8400がすでに使用されている場合、Oracle Databaseは、8400から90000までの範囲で、8400の後で次に使用可能な数値を試します。使用できないポート番号を明示的に指定すると、接続は失敗します。

各パラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。次に、トークンを取得するために対話型フローの使用を指定する例を示します。

conn /@(DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=example.us-phoenix-1.oraclecloud.com)(PORT=6010))
(SECURITY=(SSL_SERVER_DN_MATCH=YES)
(AZURE_DB_APP_ID_URI=https://oracledevelopment.onmicrosoft.com/11111111-11a1-1a11-111a-a11a11111111)
(TENANT_ID=1a111aa1-a1a1-1a11-a1a1-a11aaaaa1111)
(CLIENT_ID=aa11a111-111a-1a11-1aa1-1aa1a1aa1111)
(TOKEN_AUTH=AZURE_INTERACTIVE))(CONNECT_DATA=(SERVICE_NAME=cdb1_pdb3.regress.rdbms.dev.us.oracle.com)))
8.4.5.3 クライアント資格証明フロー

クライアント資格証明フローを使用すると、Azure以外のクラウド環境のオンプレミス・アプリケーションおよびアプリケーションは、MS-EI OAuth2トークンを取得してOracle Databaseに接続できます。

クライアント資格証明フローは、(Oracle Database 21cではなく)Oracle Database 19c以降、トークン・ファイルの受渡し方法およびOCI-CクライアントAPIを使用してサポートされています。Oracle Database 23ai OCI-Cクライアントは、MS-EIエンドポイントからのMS-EI OAuth2トークンの直接取得もサポートしており、最初にトークンを取得するスクリプトは必要ありません。クライアント資格証明フローのトークンを取得するには、MS-EIアプリ登録を使用してアプリケーションを登録するときに、クライアントIDとMS-EIからのクライアント・シークレットが必要です。これは、DBAが対話型フローを使用してデータベースに接続するためにパブリック・クライアントを設定する場合とは異なります。人間のユーザーが資格証明を使用してAzureにサインインするため、パブリック・クライアントにクライアント・シークレットは必要ありません。クライアント資格証明フローでは、MS-EIに対して認証してトークンを取得するためのクライアント・シークレットがアプリケーションに必要です。クライアント・シークレットは機密であるため、Oracle Walletを使用してクライアントIDおよびクライアント・シークレットを格納することをお薦めします。

対話型フローに使用されるクライアント(人間のユーザー用)とクライアント資格証明フロー(アプリケーション用)には、いくつかの違いがあります。対話型フローでは、ユーザーおよびグループはMS-EIエンタープライズ・アプリケーションのデータベース・アプリケーション・ロールにマップされます。クライアント資格証明フローでは、クライアント・アプリケーションはデータベース・アプリケーション・ロールにのみ直接マップできます。

Oracle DatabaseとMicrosoft Entra IDの間のクライアント資格証明フローを構成するには、次のステップに従います。

Microsoft Entra IDを使用したOracle Databaseの登録

次のMicrosoftドキュメントに従って、アプリケーション・クライアントのアプリケーション登録を作成します:
  1. アプリケーションの登録
  2. Web API登録でのスコープの公開
  3. Web APIへのスコープ権限の付与
次のことに注意してください:
  • データベース・アプリケーションの所有者であること
  • アプリケーションのデータベース・アプリケーションでアプリケーション・ロールを作成すること
  • アプリケーション・クライアント・アプリケーションのクライアント・シークレットを作成すること
  • データベース・アプリケーションに接続するためのAPI権限を作成し、それに承認を与えること

Oracle Databaseでのアプリケーション・ロール・マッピングの作成

前のステップで、新しいアプリケーション・ロールを作成しました。次に、データベースにスキーマ・マッピングを作成し、適切なロールと権限を新しいロールのスキーマに付与する必要があります。

  1. CREATE USERまたはALTER USERシステム権限を持つユーザーとして、Oracle Databaseインスタンスにログインします。
  2. Azureアプリケーション・ロール名を指定するIDENTIFIED GLOBALLY AS句を使用してCREATE USERまたはALTER USER文を実行します。
    たとえば、hr_appという名前の新しいデータベース・グローバル・ユーザー・アカウント(スキーマ)を作成し、それをhrappという名前の既存のEntra IDアプリケーション・ロールにマップするには、次のようにします:
    CREATE USER hr_app IDENTIFIED GLOBALLY AS 'AZURE_ROLE=HRAPP';

クライアント資格証明フロー用のOracle Call Interface (OCI-C)クライアントの構成

アプリケーション資格証明フローのOAuth2トークンを取得するには、OCI-Cクライアントのパラメータを定義する必要があります。

次のパラメータは、sqlnet.oraファイルまたはtnsnames.oraファイルで定義できます。tnsnames.oraファイル内のパラメータは、sqlnet.ora内の同じパラメータよりも優先されます。

パラメータ 使用上のノート
TOKEN_AUTH AZURE_SERVICE_PRINCIPAL これは、クライアント資格証明フローに従うようにOCI-Cドライバに指示します
TENANT_ID アプリケーション・アプリケーション登録のテナンシID これは、データベース・アプリケーション登録の同じテナンシである場合とそうでない場合があります
AZURE_DB_APP_ID_URI これはデータベース・アプリケーション登録からのものです これは、データベース・アプリケーション登録の作成時に構成されています
CLIENT_ID これはアプリケーション・アプリケーション登録のクライアントIDです これはデータベース・アプリケーション登録のクライアントIDではありません
AZURE_CREDENTIALS これは、クライアント・シークレットを保持するウォレットの場所です  

次に、サンプル接続文字列を示します:

conn2=
    (DESCRIPTION=
        (ADDRESS=
            (PROTOCOL=tcps)
            (HOST=phoenix99201)
             (PORT=6679)
        )
        (SECURITY=
            (SSL_SERVER_CERT_DN="C=US,O=OracleCorporation,CN=sslserver3")
            (TOKEN_AUTH=AZURE_SERVICE_PRINCIPAL)
            (TENANT_ID=aaaaaaaa-bbbb-cccc-eeee)
            (AZURE_DB_APP_ID_URI=https://examplecorp.onmicrosoft.com/aaaa-bbbb-cccc-dddd)
            (CLIENT_ID=aaaa-bbbb-cccc-dddd-eeee)
            (AZURE_CREDENTIALS=/scratch/secret)
        )
        (CONNECT_DATA=
            (SERVICE_NAME=database.examplecorp.com)
        )
    )

最初の4つのパラメータ値は、接続文字列またはsqlnet.oraファイルに含めることができます。ただし、クライアント・シークレットは、AZURE_CREDENTIALSで識別される場所にあるウォレットに存在する必要があります。

クライアント・シークレットは、ウォレット内のクライアントIDとペアになっています。データベース・ドライバは、CLIENT_IDパラメータを使用してウォレット内のクライアント・シークレットを検索します。クライアントIDは大/小文字が区別されるパラメータであるため、ウォレット内のクライアントIDの大/小文字は、接続文字列またはsqlnet.ora内のクライアントIDの大/小文字と一致する必要があります。

ウォレット・コンテンツを表示すると、次のようなものが見つかります:

oracle.security.azure.credential.<client id> = <client secret>

CLIENT_IDおよびCLIENT_SECRETはウォレット内で不明瞭化/暗号化されているため、適切な権限を持つユーザーのみが値をオープン/表示できます。

クライアント・シークレットを格納するためのウォレットの作成

orapkiを使用してウォレットを作成し、クライアント・シークレットを格納します。

  1. ウォレットを作成し、ウォレット・パスワードを設定します:
    orapki wallet create -wallet . -auto_login_only
  2. クライアントIDとクライアント・シークレットを使用してエントリを作成します:
    orapki secretstore create_entry -wallet . -alias oracle.security.azure.credential.<CLIENT_ID> -secret <CLIENT_SECRET>

    ノート:

    CLIENT_ID値は大/小文字が区別され、接続文字列またはsqlnet.oraファイルのCLIENT_ID値の大/小文字と一致する必要があります。
  • エントリを表示します:
    orapki wallet display -wallet .
  • 特定のエントリを表示します:
    orapki secretstore view_entry -wallet . -alias oracle.security.azure.credential.<CLIENT_ID>
  • エントリを変更します:
    orapki secretstore modify_entry -wallet . -alias oracle.security.azure.credential.<CLIENT_ID> -secret <CLIENT_SECRET>
  • エントリを削除します:
    orapki secretstore delete_entry -wallet . -alias oracle.security.azure.credential.<CLIENT_ID>
8.4.5.4 クライアントによるファイルの場所からのEntra IDトークンの取得の有効化

/スラッシュ・ログインの使用時に、Entra IDの場所をファイルの場所から取得することを選択した場合、クライアントを構成する必要があります。

Entra IDファイルの場所は、sqlnet.oraファイルまたはtnsnames.oraファイルのいずれかで構成できます。
  • クライアントで、tnsnames.ora接続文字列またはsqlnet.oraファイル内で次のパラメータを設定または確認します:
    • SSL_SERVER_DN_MATCH: DN一致が有効になるように、このパラメータがONに設定されていることを確認します。
    • TOKEN_AUTH: このパラメータをOAUTHに設定します。
    • TOKEN_LOCATION: このパラメータをトークンのファイルの場所に設定します。このトークンにはデフォルトの場所がありません。トークンの名前がtokenである場合は、指定する必要があるのはファイル・ディレクトリ(/test/oracle/aad-tokenなど)のみです。トークン名がtokenと異なる場合(たとえば、azure.token)、この名前をパスに含める必要があります(たとえば、/test/oracle/aad-token/azure.token)。

tnsnames.ora接続文字列のパラメータ値は、その接続のsqlnet.ora設定より優先されます。次のコードはtnsnames.oraエントリの例です。この場合、SSL_SERVER_DN_MATCHsqlnet.oraで指定され、接続文字列には表示されません:

(description= 
  (retry_count=20)(retry_delay=3)
  (address=(protocol=tcps)(port=1522)
  (host=example.us-phoenix-1.oraclecloud.com))
  (connect_data=(service_name=aaabbbccc_exampledb_high.example.oraclecloud.com))
  (security=(ssl_server_cert_dn="CN=example.uscom-east-1.oraclecloud.com, 
     OU=Oracle BMCS US, O=Example Corporation, 
     L=Redwood City, ST=California, C=US")
  (TOKEN_AUTH=OAUTH)(TOKEN_LOCATION="/oracle/tokens/aad-token"))

接続文字列がこれらのパラメータで更新された後、Azureユーザーは、まず外部ユーティリティを実行してトークンを取得し、次のコマンドを実行してSQL*Plusを起動することで、Oracle Databaseインスタンスにログインできます。接続記述子自体を含めるか、tnsnames.oraファイルからの記述子の名前を使用できます。

connect /@exampledb_high

TOKEN_AUTHは接続文字列またはsqlnet.oraファイルのいずれかによってすでに設定されているため、データベース・クライアントはAzure OAuth2トークンを取得するようにすでに構成されています。データベース・クライアントはOAuth2トークンを取得し、そのトークンをOracle Databaseインスタンスに送信します。

8.4.5.5 ネットワーク・サービス構成情報のためのAzureアプリケーション構成ストアの使用

接続文字列およびその他のネットワーク構成情報はAzureアプリケーション構成ストアに格納できます。

詳細は、『Oracle Database Net Services管理者ガイド』Azureアプリケーション構成ストアに関する項を参照してください。

8.4.6 Oracle Databaseクライアントの外部でのEntra ID OAuth2トークンの取得の例

これらの例は、データベース・クライアントを使用してトークンを直接取得していない場合に、データベース・クライアントとは別にEntra ID OAuth2トークンを取得できる様々な方法を示しています。

8.4.6.1 Oracle Databaseクライアントの外部でのMicrosoft Entra ID OAuth2トークンの取得の例について

Oracle Databaseクライアントには、Entra ID OAuth2トークンを直接取得するために様々な機能があります。

様々なフローのトークンを取得するためのデータベース・クライアントの構成については、特定のクライアント・ドキュメントを確認してください。Entra IDトークンを使用する他の2つの方法は、次のとおりです:

  • クライアントAPIを使用したトークンの受渡し
  • ファイル・システムを介したトークンの受渡し

APIの使用については、クライアント・ドキュメントを確認してください。Entra IDからトークンをリクエストし、データベース・クライアントが取得できるようトークンをファイルの場所に格納するために、ユーティリティまたはスクリプトが使用されます。スクリプトまたはユーティリティを使用したトークンのリクエストおよび格納は、Oracle Databaseの外部で行われます。Entra IDトークンの取得方法については、Microsoftやインターネット上の他のサイトから入手可能な例が多数あります。(Azure AD OAuth2トークンも検索してください)。この項のサンプルは、一部の例にすぎず、Oracleではサポートされていません。

8.4.6.2 例: 対話型(認可)フロー用のPythonスクリプトを使用したトークンのリクエスト

対話型(認可)フローは、人間のユーザーがデータベースにアクセスするための最も一般的なフローです。

ユーザーがAzureアカウントにまだログインしていない場合は、Azure資格証明の入力を求めるWebページが表示されます。また、データベースのOAuth2アクセス・トークンを取得する前に、組織が要求する多要素認証も完了する必要があります。Microsoft Authentication Library (MSAL)を使用したこの例はPythonで作成されており、Windows PowerShellやLinuxなどの様々なプラットフォームで実行できます。認可フローではAzure ADへのラウンド・トリップが2回必要であるため、MSALを使用して処理することをお薦めします。MSALでPythonスクリプトを使用する方法は、Microsoftの記事『Get Entra ID tokens by using the Microsoft Authentication Library』を参照してください。これらの手順はDatabricksサービス用ですが、Databricksスコープではなく、データベース・アプリケーションIDのURIとスコープにスコープを変更します。
  1. クライアント・アプリ登録を設定するためのステップはすでに完了しているため、このステップは省略します。ただし、クライアント・アプリ登録のリダイレクトURI (http://localhost)を追加していることを確認してください。
  2. 直接、MSAL Pythonライブラリを使用してEntra IDトークンを取得する手順に進みます。
    ディレクトリ(テナント) ID、パブリック・アプリケーション・クライアントのクライアントIDおよびデータベース・アプリケーションIDのURIおよびスコープが必要になります。scopesのコード・セクションには、この変数を変更しないようにという指示があります。このPythonコードはDatabricksスコープ用に作成されているため、このスコープ変数を、実際に使用するデータベースのスコープにあわせて変更することが必要になります。たとえば:
    scopes = ['https://example.com/1111aa1a-a1aa-1a11-11aa-1a1a11aa1111/session:connect']
  3. トークンをファイルの場所に書き込むようにコードを変更します。
    次のサンプル・コードを使用し、末尾のprint文に追加します。元のstdoutをバックアップしてリストアするための行が追加されていることに注目してください。
    stdout_backup = sys.stdout
    with open('token', 'w') as token_file:
        sys.stdout = token_file
        print(acquire_tokens_result['access_token'])
    
    sys.stdout = stdout_backup
8.4.6.3 例: 対話型(認可)フロー用のAzure CLIを使用したトークンのリクエスト

この例では、Azure CLIを使用してアクセス・トークンを取得し、取得したトークンをファイルに書き込む方法を示します。

Azure CLIのインストール方法は、Microsoftの記事『Install the Azure CLI on Linux』を参照してください。
  1. Azureテナンシにログインします。
    $ az login
  2. アクセス・トークンを取得し、次の構文を使用してトークン変数に割り当てます。
    token=$(az account get-access-token --resource=database_app_id_uri --query accessToken --output tsv)

    たとえば:

    token=$(az account get-access-token --resource=https://example.com/1111aa1a-a1aa-1a11-11aa-1a1a11aa1111 --query accessToken --output tsv)

    データベース・リソースにアクセスする権限がクライアント・アプリケーションIDにないというAzure CLIエラーが表示される場合は、エラー・メッセージからクライアント・アプリケーションIDをコピーして、データベース・リソースに対して認可されるクライアント・アプリケーションのリストに追加します。(Entra IDのデータベース・アプリ登録に移動し、「Expose an API」「Add a client application」の順にクリックします)。

  3. トークンをファイルに書き込みます。
    $ echo "$token" >> token
8.4.6.4 クライアント資格証明フロー用のAzure CLIを使用したトークンのリクエスト

クライアント資格証明フローは、Entra ID OAuth2トークンを使用してデータベースにアクセスする必要があるアプリケーションに使用されます。

アプリケーションは「ヘッドレス」であり、Azureポータルで対話的に認証するユーザーがいないため、対話型フローをアプリケーションで使用することはできません。クライアント資格証明フローは、アプリケーション用に設計されています。これらのフローでは、アプリケーションの登録には、クライアントIDとともにクライアント・シークレットが必要です。これらは、Entra ID OAuth2データベース・アクセス・トークンを取得するために使用されます。

スクリプトがトークンを取得した後、このトークンをファイルに書き込み(この項の例を参照)、データベース・クライアントがトークンにアクセスできるようにする必要があります。Microsoftでは、サービス・プリンシパルがトークンをリクエストする例をいくつか示しています。Microsoftの記事『Get Microsoft Entra ID (formerly Azure Active Directory) tokens for service principals』を参照してください。

8.4.7 データベースがインターネットに接続するためのネットワーク・プロキシの作成

このネットワーク・プロキシを使用すると、OracleデータベースはEntra IDエンドポイントに到達できるようになります。

8.4.7.1 データベースがインターネットに接続するためのネットワーク・プロキシの作成について

OracleデータベースはEntra IDエンドポイントに接続する必要があり、ネットワーク構成およびデフォルトのトラスト・ストア・アクセスが必要になる場合があります。

企業内にHTTPネットワーク・プロキシが配置されている場合、デフォルトのOracle Database環境およびOracle Real Applications Clusters環境に対してデータベースを構成できます。データベースは、Entra IDへのTransport Layer Security (TLS)リンクを確立するため、データベース・サーバー上のデフォルトのトラスト・ストアへのアクセスも必要です。これを有効にするには、データベース・サーバーがシステムのデフォルトの証明書ストアにアクセスできることを確認します。

8.4.7.2 Entra IDエンドポイントのアクセシビリティのテスト

Oracle DatabaseがEntra IDエンドポイントにアクセスできることを確認する必要があります。

データベース・クライアントがMicrosoft Entra ID OAuth2トークンを取得するように構成されている場合、データベース・クライアントはEntra IDエンドポイントにアクセスできる必要があります。次のコマンドを実行して、インターネット・アクセスがあるかどうかを確認します:
curl https://login.windows.net/common/discovery/keys
ステータス・コード200は成功を示します。

このコマンドの実行に失敗した場合は、プロキシ情報についてITヘルプ・デスクに確認してください。

OracleデータベースがEntra ID OAuth2トークンを受け入れるには、データベースがMicrosoft Entra IDエンドポイントからの公開キーをリクエストする必要があります。
  • 次のテストを実行して、データベースがMicrosoft Entra IDエンドポイントに接続できるかどうかを確認します:
    SET SERVEROUTPUT ON SIZE 40000
    DECLARE
      req UTL_HTTP.REQ;
      resp UTL_HTTP.RESP;
    BEGIN
      UTL_HTTP.SET_WALLET(path => 'system:');
      req := UTL_HTTP.BEGIN_REQUEST('https://login.windows.net/common/discovery/keys');
      resp := UTL_HTTP.GET_RESPONSE(req);
      DBMS_OUTPUT.PUT_LINE('HTTP response status code: ' || resp.status_code);
      UTL_HTTP.END_RESPONSE(resp);
    END;
    /

    このテストが成功すると、「PL/SQLプロシージャが正常に完了しました。」メッセージが表示されます。

    次のメッセージが表示された場合は、データベース・ネットワーク・アクセス制御リスト(ACL)ポリシーによってテストがブロックされたということです。テストできるようにアクセス制御リスト・ポリシーを一時的に設定する必要があります:

    ORA-29273: HTTP request failed
    ORA-24247: network access denied by access control list (ACL)
    1. ACLを次のように設定します:
      BEGIN
      DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
        host => '*',
        ace  =>  xs$ace_type(privilege_list => xs$name_list('connect'),
                             principal_name => 'username_placeholder',
                             principal_type => xs_acl.ptype_db));
      END;
      /

      username_placeholderを、テストを実行しているデータベース・ユーザーのユーザー名に置き換えます。たとえば:

      BEGIN
      DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
        host => '*',
        ace  =>  xs$ace_type(privilege_list => xs$name_list('connect'),
                             principal_name => 'DBA_DEBRA',
                             principal_type => xs_acl.ptype_db));
      END;
      /
    2. テストを再度実行します。
    3. ACLは不要になったため、削除します。たとえば、ユーザー名がdba_debraであるとします:
      BEGIN
      DBMS_NETWORK_ACL_ADMIN.REMOVE_HOST_ACE(
        host => '*',
        ace  =>  xs$ace_type(privilege_list => xs$name_list('connect'),
                             principal_name => 'DBA_DEBRA',
                             principal_type => xs_acl.ptype_db));
      END;
      /
データベースがMicrosoft Entra IDエンドポイントに接続できない場合、ACLポリシーを設定した後でも、ほとんどの場合、データベースのHTTP_PROXYパッケージを設定する必要があります。デフォルトのOracle Database環境を使用しているか、Oracle Real Application Clusters RAC環境を使用しているかに応じて、「関連トピック」にリストされているトピックを確認します。ネットワーク管理者は、正しいHTTP_PROXY設定を通知できる必要があります。
8.4.7.3 デフォルトのOracle Database環境用のネットワーク・プロキシの作成

ネットワーク・プロキシを作成するには、環境変数を設定してからリスナーを再起動する必要があります。

データベースを再起動する必要はありません。
  1. Oracleデータベースがインストールされているサーバーで、http_proxy環境変数を設定します。
    たとえば:
    export http_proxy=http://www-proxy-example.com:80/
  2. リスナーを再起動します。
    lsnrctl stop
    lsnrctl start 

    ノート:

    http_proxy環境変数を設定する必要があります。http_proxy変数ではなくhttps_proxy環境変数が設定されている場合は、http_proxy環境変数をhttps_proxy環境変数と同じ値セットに設定します。
8.4.7.4 Oracle Real Application Clusters環境用のネットワーク・プロキシの作成

ネットワーク・プロキシを作成するには、環境変数を設定してからデータベースを再起動する必要があります。

  1. Oracleデータベースがインストールされているサーバーで、http_proxy環境変数を設定します。
    ネットワーク・プロキシを設定するには、次の構文を使用します。入力するプロキシ・コマンドでは、プロキシ名の前にhttp://が必要であり、プロキシの末尾にポート番号が必要です。
    http_proxy=http://....:80/

    たとえば:

    srvctl setenv database -db db_name -env "http_proxy=http://www-proxy.example.com:80/"
  2. データベースを停止します。
    $srvctl stop database -db db_name
  3. 環境変数の値を表示して、値が正しく設定されていることを確認します。
    $ srvctl getenv database -db db_name

    次のような出力が表示されます。

    db_name:
    http_proxy=http://www-proxy.example.com:80/
    https_proxy=http://www-proxy.example.com:80/
  4. データベースを再起動します。
    $ srvctl start database -db db_name
8.4.7.5 Windowsレジストリ・エディタでのネットワーク・プロキシの作成

Windows環境でネットワーク・プロキシを作成するには、レジストリ・エディタ(regedit)を更新する必要があります。

  1. レジストリ・エディタ(regedit)を起動します。
  2. \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\OracleServicerversionキーを検索します。
  3. このキーを選択し、右側のパネルで「Environment」を見つけます。
  4. 「Environment」を編集して、新しい複数文字列値を追加します。
    次の例では、example.comのドメインを使用します:

  5. 「OK」をクリックします。
  6. データベース・サーバーを再起動します。
    たとえば:
    net start Oracle_service_name
    sqlplus "/as sysdba"
    startup;
  7. PDBを開きます。
    ALTER PLUGGABLE DATABASE ALL OPEN;

8.4.8 ネット・ネーミングおよびシークレットのための集中管理されたEntra IDサービスの使用

Azureアプリケーション構成およびAzure Vaultを使用して、ネット名とシークレットを一元的に格納できます。

この機能は現在、JDBCシン・ドライバおよび.NETシン・ドライバでサポートされています。

次のガイドを参照してください:

8.5 Microsoft Entra IDプロキシ認証の構成

プロキシ認証により、Azureユーザーは、アプリケーションのメンテナンスなどのタスクのためにデータベース・スキーマにプロキシできます。

8.5.1 Microsoft Entra IDプロキシ認証の構成について

Azureユーザーはプロキシ認証を使用して、Oracle Autonomous Databaseに接続できます。

プロキシ認証は、通常、実際のユーザーを認証し、アプリケーションを管理するためにスキーマ権限およびロールを含むデータベース・スキーマの使用をユーザーに認可するために使用されます。アプリケーション・スキーマ・パスワードの共有などの代替方法は、安全でないものとみなされ、どの実際のユーザーがアクションを実行したかを監査できません。

たとえば、アプリケーション・データベース管理者である名前付きAzureユーザーが資格証明を使用して認証し、データベース・スキーマ・ユーザー(hrappなど)にプロキシできる環境でのユースケースが考えられます。この認証により、Entra ID管理者は、アプリケーションのメンテナンスを実行するためにhrapp権限およびロールをユーザーhrappとして使用できますが、認証にはEntra ID資格証明を使用します。アプリケーション・データベース管理者は、データベースにサインインし、アプリケーション・スキーマにプロキシしてこのスキーマを管理できます。

8.5.2 プロキシ認証のためのAzureユーザーの構成

Azureユーザーのプロキシ認証を構成するには、このユーザーがすでにグローバル・スキーマへのマッピング(排他的マッピングまたは共有マッピング)を持っている必要があります。Azureユーザーがプロキシする別のデータベース・スキーマも使用可能になっている必要があります。

このタイプのユーザーがいることを確認したら、Azureユーザーにデータベース・ユーザーへのプロキシを許可するようにデータベース・ユーザーを変更します。
  1. ALTER USERシステム権限を持つユーザーとして、Autonomous Databaseインスタンスにログインします。
  2. ローカル・データベース・ユーザー・アカウントにプロキシする権限をAzureユーザーに付与します。
    コマンドではAzureユーザーを参照できないため、プロキシはデータベース・グローバル・ユーザー(Azureユーザーにマップ)とターゲット・データベース・ユーザーの間で作成する必要があります。
    次の例では、hrappはプロキシ先のデータベース・スキーマで、peterfitch_schemaはユーザーpeterfitchに排他的にマップされるデータベース・グローバル・ユーザーです。
    ALTER USER hrapp GRANT CONNECT THROUGH peterfitch_schema;
この段階で、Azureユーザーはプロキシを使用してデータベース・インスタンスにログインできます。たとえば:
CONNECT [hrapp]/@connect_string

8.5.3 Azureユーザー・プロキシ認証の検証

Azureユーザー・プロキシ構成でトークン認証を検証できます。

  1. CREATE USERおよびALTER USERシステム権限が付与されたユーザーとして、Oracle Autonomous Databaseインスタンスにログインします。
  2. Azureユーザーとして接続し、SHOW USERおよびSELECT SYS_CONTEXTコマンドを実行します。
    たとえば、データベース・ユーザーhrappにプロキシするときに、Azureユーザーpeterfitchのプロキシ認証を確認するとします:
    CONNECT [hrapp]/@connect_string
    SHOW USER;
    --The output should be USER is "HRAPP "
    SELECT SYS_CONTEXT('USERENV','AUTHENTICATION_METHOD') FROM DUAL;
    --The output should be "TOKEN_GLOBAL"
    SELECT SYS_CONTEXT('USERENV','PROXY_USER') FROM DUAL;
    --The output should be "PETERFITCH_SCHEMA"
    SELECT SYS_CONTEXT('USERENV','CURRENT_USER') FROM DUAL;
    --The output should be "HRAPP"

8.6 Microsoft Power BIシングル・サインオンの構成

Power BIユーザーのみがOracle Databaseに接続する場合、ユーザーはより簡単な構成を選択できます。

8.6.1 Microsoft Power BIシングル・サインオンの構成について

Microsoft Power BIデータ・ビジュアライゼーション・ツールのユーザーは、Microsoft Entra ID (MSEI)も頻繁に使用します。これらのユーザーは、MSEIシングル・サインオン(SSO)資格証明を使用してOracleデータ・ソースにシームレスにアクセスすることを必要としています。

以前は、Power BIユーザーは、データベースのローカルのユーザー名とパスワードを使用してOracle Databaseにアクセスするか、セキュリティ・チームが一元化されたアクセス管理を要求した場合はOracle Databaseから別のデータベースにデータを移行する必要がありました。

MSEI SSOを使用してOracleデータ・ソースにアクセスすることで、ユーザーは集中管理され、パスワード資格証明ではなくAzure ADトークンが使用されるため、セキュリティが向上します。データはOracle Databaseに残り、移行する必要がないため、DBAの使いやすさも向上します。また、ユーザーはSSOを使用してソース・データベースにアクセスできるため、データベースのパスワード資格証明を記憶して継続的にローテーションする必要もありません。

Microsoft Power BI SSOの構成は、次のものでサポートされています:

次の図は、MSEI SSOを使用して、Microsoft Power BIのソースとして使用されるOracleデータベースにアクセスする方法を示しています。

図8-6 Oracle Database for Power BIに送信されるMicrosoft Entra IDアクセス・トークン



  1. Power BIユーザーは、MSEIを使用して自身を認証します
  2. Power BIは、データベースへの接続が開くとデータベースに対するユーザーのアクセス・トークンを取得します
  3. Power BIは、MSEI Power BIアクセス・トークンをOracle Databaseに送信します
  4. Oracle DatabaseはMSEI公開キーをキャッシュし、MSEI Power BIトークンを検証します

8.6.2 Oracle Databaseの構成

Microsoft Power BIからのアクセス・トークンを受け入れるようにOracleデータベースを構成します。

前提条件:

Oracleデータベースは、MSEIアプリケーション登録で登録する必要があります。

  1. 外部アイデンティティ・プロバイダをMicrosoft Entra IDとして設定します:
    ALTER SYSTEM SET IDENTITY_PROVIDER_TYPE=AZURE_AD SCOPE=BOTH;
  2. 外部アイデンティティ・プロバイダを構成します。
    ALTER SYSTEM SET identity_provider_config='{"application_id_uri": 111-111-111, "tenant_id": "111-111-111", "app_id":"111-111-111"}';

ノート:

identity_provider_configには、Power BIアクセス・トークンの操作時にこの例で使用されている「111-111-111」などを指定できます

この構成は、Power BIユーザーSSO統合に固有のものです。完全なMSEI統合では、Power BIユーザーSSO統合もサポートされています。完全なMSEI統合により、Power BIユーザー・アクセスとSQLPlusを使用するDBA、MSEI対話型ログインとクライアント資格証明フローを使用したアプリケーションによるデータベースへのアクセスの両方が可能になります。このトピックで説明するさらに簡単なPower BI SSO構成では、Power BIユーザーのみがデータベースにアクセスできます。

MSEI完全統合の詳細は、「Microsoft Entra ID統合のためのOracle Database構成」を参照してください。

8.6.3 ユーザーの認可

Power BI Azure ADユーザーは、データベースに対して認可されている必要があります。

  1. CREATE USERおよびALTER USERシステム権限を持つユーザーとして、Oracleデータベース・インスタンスにログインします。
  2. 次のコマンドを実行して、データベースにPower BI Microsoft Entra IDユーザーを作成します:
    CREATE USER <first_last> IDENTIFIED GLOBALLY AS ‘AZURE_USER=<first.last@example.com>’;GRANT CREATE SESSION TO <first_last>;

    ユーザーが必要とするすべての権限およびロールが、データベース・スキーマ/ユーザーに付与されている必要があります。Power BIユーザーは、共有スキーマ構成を使用できません。スキーマへの排他マッピングのみを使用できます。

8.6.4 Microsoft Entra IDを使用したPower BIのOracle Databaseへの接続

データベースを構成したら、Power BI DesktopまたはServiceを構成する必要があります。

Oracleブログ「Microsoft Power BI can now connect with the Oracle Database using Microsoft Entra ID SSO tokens」の手順に従います。

8.7 Microsoft Entra ID接続のトラブルシューティング

トレース・ファイルを使用して、Microsoft Entra ID接続の問題を診断できます。ORA-12599およびORA-03114エラーを簡単に修正することもできます。

8.7.1 Oracle DatabaseクライアントとEntra IDの接続をトラブルシューティングするためのトレース・ファイル

トレース・ファイルを使用して、Oracle DatabaseとEntra IDの統合に関してトラブルシューティングできます。

8.7.1.1 接続のトラブルシューティングに使用するトレース・ファイルについて

クライアント側でEntra ID接続をトラブルシューティングするために、2つのレベルのトレース・ファイルを生成できます。

生成できるトレース・ファイルの2つのレベルは次のとおりです。

  • 低レベル・トレースでは、エラーの発生時にトレースが出力されます。
    • TCPSがEntra ID接続用に設定されていない場合は、プロトコルがTCPSである必要があるというメッセージが出力されます。
    • SSL_SERVER_DN_MATCHTRUEに設定されていない場合は、値がFALSEであるというメッセージが出力されます。
    • TOKEN_LOCATIONが指定されていない場合は、トークンの場所が存在しないというメッセージが出力されます。
    • 指定されたTOKEN_LOCATIONにトークンが存在しない場合は、メッセージが出力されます。
    • OCI_ATTR_TOKEN_ISBEARERをtrueに設定せずにアプリケーションがトークンを渡した場合、欠落している属性についてのメッセージが出力されます。
    • アプリケーションがOCI_ATTR_TOKEN_ISBEARERTRUEに設定し、トークンを渡さなかった場合、欠落している属性についてのメッセージが出力されます。
    • トークンが期限切れの場合は、メッセージが出力されます。
    • トークンがMicrosoft Entra ID v2.0トークンで、upnクレームまたはロール・クレームが含まれていない場合、必要なクレームがないというメッセージが出力されます。
  • 高レベル・トレースでは、前述のようにエラーの発生時にトレースが出力されます。さらに、次のように、成功時にトレースが出力されます。
    • SSL_SERVER_DN_MATCHが存在する場所(tnsnames.oraまたはsqlnet.ora)が出力されます。また、TRUEに設定されている場合は、TRUEの値が出力されます。
    • アプリケーションでトークンとOCI_ATTR_TOKEN_ISBEARER=trueの両方が設定されている場合は、メッセージが出力されます。
    • TOKEN_AUTHに、正しい値OAUTHが設定されている場合は、その値が出力されます。
    • トークンが期限切れでない場合は、メッセージが出力されます。
    • トークンがMicrosoft Entra ID v2.0トークンで、upnクレームまたはロール・クレームが存在する場合、必要なクレームが存在するというメッセージが出力されます。
8.7.1.2 トークン認証のクライアント・トレースの設定

クライアント側のsqlnet.oraファイルにEVENT設定を追加して、クライアント・トレースを制御できます。

これらのEVENT設定は、IAMおよびEntra IDの両方でOracle Databaseとの接続に使用できます。
  • 次のいずれかの方法を使用します。
    • クライアント側のsqlnet.oraファイルに次の設定を追加します。
      • EVENT_25701=14 (低レベル・トレースの場合)
      • EVENT_25701=15 (高レベル・トレースの場合)
    • 環境変数EVENT_25701を設定します。
      • EVENT_25701=14 (低レベル・トレースの場合)
      • EVENT_25701=15 (高レベル・トレースの場合)
    クライアント・トレース・ファイルは、次の場所に作成されます。
    • Linux: $ORACLE_HOME/log/diag/clients
    • Windows: %ORACLE_HOME%\log\diag\clients

    クライアント側のsqlnet.oraADR_BASEパラメータを使用して、トレース・メッセージが格納されるディレクトリを指定できます。ディレクトリ・パスが有効で、書込み権限があることを確認します。DIAG_ADR_ENABLEDパラメータがFALSEに設定されていないことを確認します。

    ADR_BASEの設定例を次に示します。

    ADR_BASE=/oracle/oauth2/trace

8.7.2 トークンを使用してデータベースにアクセスしようとしたときにORA-12599およびORA-03114エラーが発生する

ORA-12599: 「TNS: 暗号チェックサムの不一致が発生しました」エラーおよびORA-03114: 「Oracleに接続されていません。」エラーは、接続しようとしているデータベースがネイティブ・ネットワーク暗号化によって保護されていることを示します。

トークンを使用してOracleデータベースにアクセスする場合は、ネットワーク・ネイティブ暗号化ではなくTransport Layer Security (TLS)接続を確立する必要があります。これらのエラーを修正するには、TLSがデータベースに対して適切に構成されていることを確認してください。ローカル・データベースのユーザー名とパスワードを使用して構成をテストし、次のSYSCONTEXT USERENVパラメータを確認する必要があります。

  • NETWORK_PROTOCOL

  • TLS_VERSION

8.7.3 Entra IDアクセス・トークン・バージョンの確認

JSON WebトークンのWebサイトを使用すると、サイトで使用されているEntra IDアクセス・トークンのバージョンを確認できます。

デフォルトではEntra ID v1アクセス・トークンですが、サイトでv2の使用が選択されている場合があります。Oracle Databaseではv1トークンがサポートされており、Autonomous Database Serverlessではv2トークンもサポートされています。v2アクセス・トークンを使用する必要がある場合は、Oracleデータベースに対してそれらの使用を有効にできます。使用しているEntra IDアクセス・トークンのバージョンを検索するには、次のようにEntra ID管理者に問い合せるか、JSON WebトークンのWebサイトからバージョンを確認できます。
  1. JSON WebトークンのWebサイトにアクセスします。
    https://jwt.io/
  2. トークン文字列をコピーして「エンコード」フィールドに貼り付けます。
  3. デコードフィールドを確認します。ここにはトークン文字列に関する情報が表示されています。
    そのフィールドの近くか下部に、次のバージョンのいずれかを示すverというクレームが表示されます。
    • "ver": "1.0"
    • "ver": "2.0"