待ちに待った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版ポータルは
もしくは、
あたりからアクセスできます。
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へシームレスに移行する際には本領を発揮することになると思います。
このあたりのシナリオもまた検証してみたいと思いますので、またそのうち公開するかも知れません。
投稿
0 件のコメント:
コメントを投稿