[Azure AD]PingAccess連携でオンプレ資産へのアクセスを拡張する

こんにちは、富士榮です。

待ちに待ったPingAccess+Azure AD連携のパブリック・プレビューが始まりました。
昨年のTechSummitで少しだけ紹介しましたが、当時はプライベート・プレビュー段階だったのでお見せ出来ず。。。

アナウンス
　公式blog
　PingAccess for Azure AD: The public preview is being deployed!
　https://blogs.technet.microsoft.com/enterprisemobility/2017/03/22/pingaccess-for-azure-ad-the-public-preview-is-being-deployed/


簡単に言うと、Azure AD Web Application Proxy（Azure AD WAP）を経由してPingAccessのサーバをインターネットへ公開、PingAccessのリバースプロキシ配下のアプリケーションへアクセスを可能にする、という構成が取れるようになります。

このことにより、これまでAzure AD WAPではバックエンドのアプリケーションは統合Windows認証が前提だったのが、HTTPヘッダ認証のアプリケーションなどPingAccessが対応している認証方式のアプリケーションであれば外部に公開することが出来るようになります。


とりあえず今回はHTTPヘッダ認証を使ったアプリケーションとの連携を公式ドキュメントの手順＋αでやってみたいと思います。
（ちなみに公式ドキュメントが一部間違っているので・・・）

参考手順はこちら
　Azure AD側
　https://docs.microsoft.com/en-us/azure/active-directory/application-proxy-ping-access

　PingAccess側
　https://docs.pingidentity.com/bundle/paaad_m_ConfigurePAforMSAzureADSolution_paaad43/page/pa_c_PAAzureSolutionOverview.html


では早速。

◆Azure AD WAP経由で公開するオンプレミスアプリケーション定義を作成する

通常のAzure AD WAPでオンプレミスアプリケーションを公開するのと同じ手順で、PingAccessサーバを公開します。この段階ではPingAccessはまだダウンロード・インストールはしていないので内部URLなどは適当なものを設定しておき、あとで修正しても問題ありません。

Azure ADポータルよりエンタープライズアプリケーションの登録を行います。アプリケーションの種類は「オンプレミスのアプリケーション」を指定します。

内部URL、公開URL、認証方式などの設定を以下の通り行います。

• 内部URL

• Azure AD WAP ConnectorからアクセスできるPingAccessサーバのURLです。今回はPingAccessとConnectorを同じサーバにインストールしたので、https://localhost:3000としています。
• 尚、公式ドキュメントでは内部URLにもアプリケーションパスを追加する、とありますが、Azure ADで認証された後、認可コードをPingAccessサーバのコールバックエンドポイントへGETで渡す必要があるので、アプリケーションパスを追加するとコールバックエンドポイントへアクセスできず、うまく動かないのでパスを追加してはいけません。
• また、PingAccessサーバがhttpsで動いているので、Connectorサーバからのアクセス時に証明書エラーが起きないように、一旦ConnectorサーバでPingAccessサーバへアクセス、証明書をインストール、エラーが起きない状態にしておく必要があります。

• 公開URL
• ここは適当に設定します。後で使うので値は覚えておきましょう。
• 事前認証
• Azure ADで認証するので当然Azure ADを選択します。
• ヘッダーのURL変換
• 「いいえ」を選択します。
• コネクタグループ
• PingAccess用のAzure AD WAP Connectorが属しているコネクタグループを選択します。

こんな感じです。

次にシングルサインオン設定を行います。

これまで出てこなかった、「Header-based Sign-on」が認証方式として選択できるようになっているので、これを設定します。

※ちなみにテナントによっては出てこない場合があるので、その場合はPreview版のAzure ポータルからAzure ADにアクセスしてみてください。私の環境では一度Previewポータルで設定をしたら次からは現ポータルでも出てくるようになりました。

　Preview版ポータルは

　　https://preview.portal.azure.com/

　もしくは、

　　https://ms.portal.azure.com/

　あたりからアクセスできます。

Header-based Sign-onを選択するとPingIdentityのロゴとともに、PingAccessのダウンロードサイトへのリンクが出てきますので、アクセスします。

リンクを開くとPingIdentityの登録サイトへ行くので名前などを登録します。

登録するとメールが届き、その中にモジュールとライセンスのダウンロードページへのリンクが入っているのでアクセスします。リンクは7日間有効だそうです。

ここで各プラットフォーム用のモジュールとライセンスのダウンロードができます。

ちなみに、普通のPingAccessのサイトからダウンロード（現時点では4.2.2）できるモジュールとこのサイトからダウンロードできるモジュール（4.3.0BETA）は別物なのでここからダウンロードしてください。（そのうち統一されるとは思いますが）

◆PingAccessがAzure ADからid_tokenをするためクライアント登録を行う

PingAccessはAzure ADから渡されたid_tokenの中のClaimをヘッダにマッピングするだけなので、先ほど作成したアプリケーションにscopeの設定、client_idとclient_secretの取得をしておく必要があります。

先ほどはエンタープライズアプリケーションの設定メニューでしたが、この設定を入れるにはアプリの登録メニューから操作を行う必要があります。

アプリの登録メニューから先ほど作成したエンタープライズアプリケーションを探して開きます。

まずはAPIアクセスの許可です。

• 対象API
• Windows Azure Active Directory
• 必要なスコープ
• アプリケーションへのアクセス許可
• Read and write all applications
• 委任されたアクセス許可
• Sign in and read user profile

次にclient_secretの作成です。Azure AD用語ではキーですので開いて作成・保存します。

保存するとキーが表示されるので、控えておきます。

同様にclient_idはアプリケーションIDなのでこの値も、そしてディレクトリID（Active Directoryのプロパティから確認できます）を控えておきます。

ここまででPingAccessの設定に必要な情報はそろいました。

尚、公式手順を見るとReply UrlにAzure AD WAPの外部URLが設定されていることを確認し、必要に応じて手動設定すること、という説明がありますが特に問題なく自動設定されました。

◆PingAccessのインストールとライセンス設定

いよいよPingAccessのインストールと設定です。先ほどのPingIdentityのページよりダウンロードしたモジュールを使います。

今回はWindows Server 2016のサーバにAzure AD WAP Connectorと同居する形でインストールしました。

MSIモジュールを実行すると以下の通りインストールが走ります。基本的には次へ、次へでOKです。ちなみに事前にJRE1.8以降がインストールされておりJAVA_HOMEが環境変数に設定されている必要があります。

とりあえずスタンドアロン版にしていますが、プロダクション環境ではクラスタを作ることになると思います。

取り敢えずインストールは簡単ですね。

次は設定を行います。

まずはブラウザで管理コンソールへアクセスします。デフォルトインストールだと

　https://サーバ:9000/

でアクセスできます。

初回アクセスの場合、ライセンスのアップロードが求められるので先にダウンロードしたライセンスファイル（zip）を解凍して出来るlicファイルを選択してアップロードします。

上手くライセンスが登録されると、管理者でログインが求められます。

初期状態ではID：Administrator、パスワード：2Accessでアクセスできます。

初回ログインが成功するとパスワード変更が求められますので適当に変更しておきましょう。

これでようやく管理コンソールが開きます。

◆PingAccessとAzure ADの連携設定、バックエンドアプリへのプロキシ設定を行う

いよいよAzure ADとの連携設定です。

まず、SystemメニューよりTOKEN PROVIDERを開きます。

流石専用版、ISSUERに最初からAzure ADのURLが固定で入っているので、先ほど確認したディレクトリIDを設定してSAVEします。

次に、VirtualHostの設定です。要するにAzure AD WAPからアクセスが来た場合の挙動の設定をするための入れ物です。

HOSTに先ほどAzure AD WAPの設定の時に指定した外部URLのホスト名パートを設定し、PORTには443を設定しておきます。

次は、WEB SESSIONの指定をします。Azure ADから取得したid_tokenを使ってセッションを生成するので、先に取得したclient_id、client_secretはここで使います。

NAMEは適当に、COOKIE TYPEはSigned JWT、AUDIENCEはCookie名になるのでそれなりの値を設定します。

次に先ほどAzure ADで取得したclient_idとclient_secretを指定します。

次は、id_tokenから取得したClaimをヘッダへ変換するためのマッピング設定を行います。IDENTITY MAPPINGから設定していきます。

TYPEにHeader Identity Mappingを設定して、、

id_tokenの中のClaim名とヘッダ名をマッピングしていきます。

ここまででAzure ADとの連携部分は終わりなので、後はバックエンドサーバの設定をしていきます。まずはSite設定です。Sitesメニューを開き、Add Sitesをクリックします。

ここが実際のバックエンドサーバのアドレスやURLを入れる部分なので、今回は手元にあったCentOSのApache CGIを指定してみたいと思います。

適当な名前を設定して、TARGETSにサーバアドレスを指定します。

最後にここまでに設定してきた内容を組み合わせてPingAccess上でApplicationとして定義を行います。Applicationsメニューを開き、Add Applicationをクリックします。

名前は適当に。CONTEXT ROOTにはリバースプロキシとしてのパス設定なので、バックエンドアプリケーションのパスを指定します。今回はcgiを動かしてみようと思うので、/cgi-binを公開します。

後は、VIRTUAL HOST、WEB SESSION、SITEなどここまでに定義したものを設定していきます。

同様にIDENTITY MAPPINGも選択し、最後に「ENABLED」にチェックを入れてSaveします。

これで設定は完了です。

早速テストしてみましょう。

◆動作確認

Azure AD WAPに設定した外部URLに、今回PingAccessで公開しているバックエンドサーバのパスを付けたものへアクセスしてみます。

　今回だとこんな感じです。

　https://pingaccess-pharaoh.msappproxy.net/cgi-bin/

すると、Azure AD WAPに事前認証として指定した通り、Azure ADのログオンがおこなわれ、PingAccessからAzure ADへのアクセスに関する許可が求められます。（初回のみ）

そして、うまくいくとPingAccess配下のアプリケーションが表示され、ヘッダにマッピング設定した通りに値が表示されます。

もちろんテスト前にAzure ADでアプリケーションへユーザの割り当てをしておいてください。

今回はPingAccessのリバースプロキシ配下のアプリケーションへHTTPヘッダでAzure ADのClaimを渡すというシナリオだったので、mod_auth_openidcとmod_proxyを使って同じような環境は割と簡単に作れるとは思います。
　参考）CentOS+Apacheの認証をAzure AD/OpenID Connectで行う
　　　http://idmlab.eidentity.jp/2017/01/centosapacheazure-adopenid-connect.html

PingAccess連携を使うメリットは既にPingAccessで構成されたアプリケーション資産が存在していたり、Agent型でPingAccessが構成されているような場合に最大化されます。また、PingAccess自体が他のWAM製品との連携（というか他製品のフリをする）が得意な製品なので、Oracle Access ManagerやIceWallなどが既存で入っている環境をAzure ADへシームレスに移行する際には本領を発揮することになると思います。

このあたりのシナリオもまた検証してみたいと思いますので、またそのうち公開するかも知れません。