Autonomous DatabaseのAPEXで、アプリケーション・ビルダーのサインインにSocial Sign-Inが使えるようになりました。手順自体は以前に書いた記事 - Azure ADで認証しMicrosoft Graph APIを呼び出す - とあまり違いはありません。
以前の記事を書いたのは１年以上前になります。ADB、APEXおよびAzure ADの画面が変更されているため、作業を一通りやり直してみました。
検証にはAlways FreeのAutonomous Transaction Processingを使用しています。ADBのインスタンスを作成した後、開発用のワークスペースとしてAPEXDEVを追加した状態から作業を始めます。
以下より作業手順を記載します。
最初にAzure ADにアプリケーションを登録します。
Azureのポータルhttps://portal.azure.comにアクセスします。AzureサービスのAzure Active Directoryを開きます。左上のメニューを開いて、Azure Active Directoryを呼び出すこともできます。
アプリの登録を開きます。
画面の下にアプリケーションの登録を追加というショートカットがあるので、それを呼び出すこともできます。エンタープライズアプリケーションの追加ではありません。
アプリの登録の新規登録を実行します。
アプリケーションの登録画面が開きます。
アプリケーションの名前は任意です。今回はAPEXDEV Adminとしています。サポートされているアカウントの種類として、この組織ディレクトリのみに含まれるアカウント（規定のディレクトリのみ - シングルテナント）を選択します。以前の記事では、任意の組織ディレクトリ内のアカウント（任意のAzure ADディレクトリ - マルチテナント）と個人のMicrosoftアカウント（Skype、Xboxなど）を選んでいます。こちらを選択しても同様に、Azure ADを使ったユーザー認証を構成することができます。リダイレクトURIは、Oracle APEX側で認証応答を受け付けるURIです。APEXのサーバーのベース・パスにapex_authentication.callbackを付加したURIになります。省略可能となっていますが、APEXでの認証では指定は必須です。
https://<ADBのID>-<ADBインスタンス名>.adb.<リージョン名>.oraclecloudapps.com/ords/apex_authentication.callback
以上を設定し、登録を実行します。
アプリケーションAPEXDEV Adminが作成されます。アプリケーション(クライアント)IDの情報をOracle APEXにOAuth2資格証明のクライアントIDとして登録するので、コピーしておきます。
アカウントの種類として、任意の組織ディレクトリ内のアカウント（任意のAzure ADディレクトリ - マルチテナント）と個人のMicrosoftアカウント（Skype、Xboxなど）を選択している場合は、OpenID Connect メタデータ ドキュメントのURLは以下になります。
https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration
このURLを、APEXにDiscovery URLとして登録します。Azure ADに登録したアプリケーションによって異なるため、必ずエンドポイントを開いて確認します。
証明書とシークレットを開き、新しいクライアント シークレットを作成します。
画面右にドロワーが開きます。説明を入力し、有効期限を選択します。今回は説明にAPEXDEV Admin、有効期限は推奨: ６か月を選択しています。
追加をクリックします。
クライアント シークレットが作成されます。この値をAPEX側のクライアント・シークレットまたはパスワードとして登録します。シークレットIDは使用しません。
クライアント シークレットの値をコピーしておきます。
有効期限が切れる前に新しくクライアント シークレットを作成し、APEX側のクライアント・シークレットまたはパスワードを更新する必要があります。
プロパティのメールが空白の場合は、IDと同じ値を設定します。プロパティを変更した後、保存をクリックします。
Azure Active Directoryでの設定は以上で完了です。
パスワード(ワークスペース・ユーザー・アカウント・リポジトリに対してのみの認証用)を入力します。アプリケーション・ビルダーへのサインインには、Azure ADが使用されるため、ここで指定するパスワードは使用されません。
apex_instance_admin.set_parameter('APEX_BUILDER_AUTHENTICATION','DB');
通知の送信を行います。
APEXの管理サービスにサインインします。ユーザーADMINのパスワードを入力します。
最初にAzure ADの既定のディレクトリに登録されているユーザーを、Oracle APEXに登録します。Azure ADのユーザーと同じ名前のユーザーをOracle APEXに登録することにより、そのユーザーでの認証をAzure ADで実施します。
ワークスペースの管理を開きます。
開発者とユーザーの管理を開きます。
ユーザーの作成をクリックします。
ユーザーを作成します。
ユーザー名、電子メール・アドレスとして、AzureポータルにサインインしたユーザーのIDを大文字で入力します。その他のユーザー属性として、名、姓を入力します。
アカウント権限のワークスペースとしてINTERNALを選択します。管理者ユーザーとしてはいを選択します。
以上を設定し、作成を実行します。
同じ手順を繰り返し、別のワークスペースに同じユーザー名のユーザー（Azureポータルにサインインしたユーザー）を作成します。
アカウント権限のワークスペースにAPEXDEV（アプリケーションを開発するためのワークスペース）を選択します。
ワークスペースINTERNALとAPEXDEVに、同じ名前のユーザーが作成されました。
続いて、Social Sign-Inの設定を行います。
インスタンスの管理を開きます。
インスタンスの設定のセキュリティを開きます。
認証制御の開発環境認証スキームのSocial Sign-Inを開きます。
クライアントIDとして、Azure ADに登録したアプリのアプリケーション(クライアント)IDを指定します。クライアント・シークレットとして、Azure ADのアプリに作成したクライアント・シークレットの値を指定します。
認証スキーム属性のAuthentication ProviderとしてOpenID Connect Providerを選択し、Discovery URLとして、Azure ADのアプリのエンドポイントを開いて確認した、OpenID Connect メタデータ ドキュメントのURLを指定します。
Scopeはemail、Username Attributeもemailとし、Verify Usernameにはいを指定して、変更の適用を実行します。
APEXの開発環境認証スキームが設定されました。再度、Social Sign-Inを開き、Social Sign-Inをカレントのスキームに切り替えます。
カレント・スキームにするをクリックします。
開発環境の認証スキームを切り替えると、認証スキームの設定に不備があるとサインインができなくなると警告されます。メッセージでは認証スキームとしてOracle APEX Accountsに戻すコマンドが示されています。Autonomous Databaseの場合は、Database Accountsに戻す必要があります。以下のコマンドをデータベース・アクションのSQLで実行すると、認証スキームを戻すことができます。
開発環境認証スキームとしてSocial Sign-Inがカレントに変わります。
以上で、開発環境の認証にAzure ADを使う設定ができました。
実際にサインインを行ってみます。以下のURLにアクセスします。
https://<ADBのID>-<ADBインスタンス名>.adb.<リージョン名>.oraclecloudapps.com/ords/
Microsoftのサインイン画面が開きます。アカウントを選択します。これからの手順は、Microsoft Authenticatorを使って認証を行なっています。
Microsoft Authenticatorでの承認待ちになります。
サインインの状態を維持しますか？と確認されます。この選択は、どちらでも構いません。
サインインが完了します。操作できるワークスペースが一覧されます。
アプリケーション・ビルダーにサインインするため、APEXDEVを選択します。
なお、設定に問題がありAzure ADをによるサインインに失敗した場合は、管理サービスにもサインインできません。
その場合は、データベース・アクションのSQLを開き、以下のコマンドを実行します。
BEGIN
apex_instance_admin.set_parameter('APEX_BUILDER_AUTHENTICATION','DB');
end;
認証スキームをDatabase Accountsに戻した後は、ユーザーADMINにて管理サービスにサインインできます。
元々はデータベース管理者の名前はADMIN決め打ちで、入力フィールドは存在しません。上記の手順で認証スキームを回復すると、データベースのユーザー名の入力フィールドが表示されるようになります。こちらは常にADMINと入力します。
以上になります。
完
