Azure ADを使って、Oracle APEXのアプリケーションをSAMLで認証させてみました。
Oracle APEX側の準備は、おおむねOktaを使ってSAML認証の設定を行ったときと同じです。そのため、Azure AD側での作業を主に記述します。
以下、作業手順になります。
https://portal.azure.comにアクセスし、ナビゲーション・メニューからAzure Active Directoryを開きます。
Microsoft Entra admin centerが開きます。
ナビゲーション・メニューのApplicationsのエンタープライズアプリケーションを開きます。
開いた画面で＋新しいアプリケーションをクリックします。
Oracle APEXは事前に連携がされているアプリケーションではないため、＋独自のアプリケーションの作成をクリックします。
右側にドロワーが開きます。お使いのアプリの名前は何ですか？という問い合わせにapexと入力します。Azure AD側ではアプリと言っていますが、Oracle APEXの場合は個々のアプリではなく、インスタンス全体をここでいうアプリとして登録します。そのため、ここではAPEXが動いているインスタンス名のような名前を指定することになるでしょう。
名前にapexと入力すると、エントリと一致する可能性がある次のアプリケーションが見つかりました、と候補が表示されます。選択できる候補は無いので、ギャラリーに見つからないその他のアプリケーションを統合します（ギャラリー以外）を選択します。
作成をクリックします。
エンタープライズアプリケーションとしてapexが作成されます。
SAMLの設定は、2。シングルサインオンの設定に含まれています。今回の作業は、この他に1。ユーザーとグループの割り当てだけです。
2。シングルサインオンの設定の作業の開始のリンクをクリックします。
SAMLによるシングルサインオンのセットアップとして、実施する手順が１から５まで順番に提示されます。
最初の基本的なSAML構成から実施します。編集をクリックします。
識別子(エンティティID)、応答URL(Assertion Consumer Service URL)、サインオンURL(省略可能)の３つすべてに、Oracle APEX側で定義されているSAMLコールバックURLを設定します。
以下のような形式のURLです。apex_authentication.saml_callbackの部分は、どのインスタンスでも同じです。ベースとなるURLはOracle APEXが稼働している環境に合わせて変更します。
https://test.mydomain.dev/ords/xepdb1/apex_authentication.saml_callback
https://test.mydomain.dev/ords/apex_authentication.saml_callback
以上の設定を保存します。
２の属性とクレームは、デフォルトのままにしておきます。
３のSAML署名証明書の編集をクリックします。
署名オプションをSAML応答とアサーションへの署名に変更します。署名アルゴリズムはSHA-256のまま変更しません。
以上の変更を実施し、保存します。
アクティブな証明書の操作メニューを開き、PEM証明書のダウンロードを実行します。アプリケーション名.pem、今回の例ではapex.pemというファイル名で、PEM形式の証明書がダウンロードされます。
以上の作業を行い、ドロワーを閉じます。
Azure AD側のSAMLの設定は以上になります。
これからOracle APEX側の設定を行います。
Azure ADの５のapexのセットアップ（apexの部分はアプリケーション名で、作業によって変わります）の記述を参照します。
Oracle APEXの管理サービスにサインインし、SAMLの構成画面を開きます。（ナビゲーション・パスはインスタンスの管理>セキュリティ>認証制御>SAMLです。スクリーンショットはOktaの記事を参照してください。）
内部およびワークスペース・アプリケーション用のSAML: APEX属性のアプリケーションのSAML有効化をONにします。証明書と秘密キーは、Oktaのときと同様にopensslを使って秘密キーと自己署名証明書を生成したものを貼り付けます。Oracle APEXの設定で必須なので指定しますが、SAML認証には使用されません。
内部およびワークスペース・アプリケーション用のSAML: アイデンティティ・プロバイダ属性を設定します。
発行者としてAzure AD識別子、署名証明書はAzure ADからダウンロードした証明書（今回であればapex.pemの内容）、サインインURLとしてログインURL、サインアウトURLとしてログアウトURLを設定します。
以上で変更の適用をします。
ORDSのCORS設定で、アクセスを許可するOriginはhttps://login.microsoftonline.comでした。
ORDS 22.1では以下のコマンドを実行します。ordsコマンドのパスや構成ファイルの位置は、それぞれのインストールで異なります。
ORDS 21.xでは以下のコマンドを実行します。
java -jar ords.war set-property security.externalSessionTrustedOrigins https://login.microsoftonline.com
変更を反映するには、ORDSの再起動が必要です。
以上でOracle APEX側の設定は完了です。
Azure AD側で１。ユーザーとグループの割り当てを行います。
＋ユーザーまたはグループの追加をクリックします。
ユーザーを選択します。現在Microsoft Entra admin centerを開いているユーザーは作成済みなので、そのユーザーを割り当てます。
選択されていませんのリンクをクリックします。
ENTERPRISE MOBILITY + SECURITY E5もしくはAZURE AD PREMIUM P2のサブスクリプションを購入するとグループの割り当てもできるとのことです。無料試用版も提供されています。今回の検証ではグループは使いません。
サインインを許可するユーザーをクリックして選択したアイテムに移動させた後、選択をクリックします。
以上でAzure ADとOracle APEXの双方の設定は完了です。
SAMLによるサインインを確認するために作成したアプリケーションにアクセスし、設定を確認します。
https://ホスト名/ords/PDB名/r/ワークスペース名/samltest/home
今回の例では、以下のURLにアクセスします。
https://test.mydomain.dev/ords/xepdb1/r/apexdev/samltest/home
Microsoftのサインイン画面が表示されます。Microsoftとの契約状況（私はMIcrosoft 365の契約があります）やユーザーの設定状況によって、サインイン画面は違うのではないかと思います。
アカウントを選択すると、（私の場合は）通知の送信を行う画面が開きました。
Microsoft Authenticatorによる承認待ちになります。
サインインの状態を維持しますか？と確認されます。はいかいいえのどちらかを選択します。
APEXのアプリケーションのAPP_USERもシステムで一意でなければならない値なので、Azure AD側で一意性が保証されている値を設定する必要があります。
そのため、対応としてはAPP_USER自体を変更するのではなく、アプリケーション側でAPP_USERを表示に使用している部分を、人が見てわかる表示（姓名など）に変更します。
Azure ADのデフォルト設定では、SAML 2.0 Assertionに表示名（AttributeのName属性がhttp://schemas.microsoft.com/identity/claims/displayname）と電子メール・アドレス（AttributeのName属性がhttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress）が含まれています。これを認証スキームの認証後のプロシージャで取り出し、アプリケーション・アイテムG_DISPLAY_NAME、G_EMAILADDRESSに設定します。
共有コンポーネントのアプリケーション・アイテムとして、G_DISPLAY_NAME、G_EMAILADDRESSを作成します。
表示名と電子メール・アドレスの取り出しコードは、以下になります。
このPL/SQLコードを認証スキームSAMLサインインのソースのPL/SQLコードに記述し、ログイン・プロセスの認証後のプロシージャ名としてget_user_profilesを設定します。
ナビゲーション・バーの表示を変更するため、共有コンポーネントのナビゲーション・バー・リストを開きます。
ナビゲーション・バーを開きます。
リスト・エントリ・ラベルを&APP_USER.から&G_DISPLAY_NAME.に変更します。
変更の適用をクリックすると、ナビゲーション・メニューの変更は完了です。
ユーザー名が小文字のみで表示されないようにするには、同じページのユーザー定義属性のList Item CSS Classesとして設定されているhas-usernameを削除します。
以上の変更を行い、再度、SAML認証の確認アプリケーションにアクセスします。
以上で、Azure ADを使ってAPEXアプリをSAMLで認証するための作業は終了です。
サブスクリプションの関係で、Azure ADでは認証後のプロシージャにてダイナミック・グループの割り当ては行っていません。おそらくAzure ADでもAssertionにグループ情報が含まれることになるので、Oktaの処理とおおむね同じコードで対応できると思います。
完
