2017年6月19日月曜日

[Azure AD] PingAccess連携が正式リリース

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

遂にAzure ADとPingAccessとの連携機能が正式リリースされました。Public Preview公開から約3月で正式リリースされたので、かなり早いペースで出てきましたね。
やはり今週シカゴで開催されているCloud Identity Summit(PingIdentity主催)に合わせて来た、というところでしょう。

公式Blogでのアナウンス
 Ping Access for Azure AD is now Generally Available (GA)!
 https://blogs.technet.microsoft.com/enterprisemobility/2017/06/15/ping-access-for-azure-ad-is-now-generally-available-ga/

画像出典:公式blog

出来ることは、Azure AD Web Application Proxyを使ってPingAccessへの認証をAzure ADで行うことにより、PingAccess配下(リバプロ、エージェント)のアプリケーションへのシングルサインオンを実現する、というようなところです。

詳しくは以前紹介したこちらのポストを参照してください。
 [Azure AD]PingAccess連携でオンプレ資産へのアクセスを拡張する
 http://idmlab.eidentity.jp/2017/03/azure-adpingaccess.html

 [Azure AD+PingAccess]Basic認証のあるバックエンドサイトへアクセスする
 http://idmlab.eidentity.jp/2017/03/azure-adpingaccessbasic.html


2017年6月15日木曜日

[Azure AD/Windows 10]外部SAML IdPとID連携しているとAzure AD Joinできない

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

今回はかなり、レアかつマニアックな話です。
以前、Office365へOpenAMを使ってログインする方法を紹介しました。

 [Office365/AzureAD]OpenAMとのID連携①
 http://idmlab.eidentity.jp/2014/11/office365azureadopenamid.html


Azure ADは純正の外部IdPであるAD FS以外にもws-federationもしくはSAMLに対応した外部IdPとのフェデレーションもサポートしているので、OpenAMやPingFederateなどのサードパーティIdPでOffice365などAzure ADと連携されているアプリケーションへのログインが可能になる、という事です。

通常のWebアプリケーションであれば問題はないのですが、実はWindows 10のAzure AD Join(いわゆるWorkplace Joinではなく)を外部SAML IdPと連携したAzure ADで実行しようとすると問題が起きます。
(外部IdPがws-federationだと行けます。本国の方々と話をしていたんですが、あまりにもレアケースなので・・・という感じでした。まぁ、確かに。)

ということで、現状はAD FS以外の外部IdPと連携したAzure ADへのWindows 10デバイスの直接参加は不可能なので、もし将来的にAzure AD Joinを行う計画のある人は外部SAML IdPを使うのはやめておいた方が良いかも知れません。
注)AD FSを使う場合も正規の手続き(Convert-MsolDomainToFederated)以外を使った場合(Set-MsolDomainAuthenticationでプロトコルにSAMLを指定)は他の外部SAML IdPと同様にAzure AD Joinが出来なくなります。


では、どんなことが起きるのか、何が原因なのか、について少しだけ解説しておきます。

◆何が起きるのか?

[設定]からAzure ADへの参加を使用とすると「職場または学校のアカウント」の入力を求められます。


正規の手順で構成されたAD FSを使っている場合は、ユーザ名を入力して[次へ]をクリックすると組織のサインインページ(要はAD FSのログイン画面)へ遷移します。


しかし、その他の外部SAML IdPを使っている場合は以下の様に「組織のアカウントではない」と怒られてしまい、Azure AD Joinが出来ません。


◆何が起きているのか?

Azure ADへのサインインを行う際、入力したユーザがどこで認証されるべきか?をドメインパート(@より後ろ)を見て判別する、いういわゆるホームレルムディスカバリというプロセスが実行されます。これは、ブラウザシナリオでも今回のような非ブラウザシナリオでも同様です。

今回ブラウザシナリオでは外部IdPを使ってもログインできて、Azure AD Joinの場合だけダメなのか?はこのホームレルムディスカバリの方法と仕様が異なるためです。

ブラウザシナリオにおいては
 https://login.microsoftonline.com/common/userrealm
というエンドポイントにクエリパラメータに「user=ユーザ名」をつけたGETリクエストを行うのに対し、Azure AD Joinの場合は、
 https://login.microsoftonline.com/common/GetCredentialType
というエンドポイントにユーザ名の情報をPOSTします。
※ちなみにワークプレイスジョイン(組織アカウントの追加)の場合はブラウザシナリオと同じエンドポイントを使うので、外部SAML IdPを使っても問題なくサインインできます。

エンドポイントが異なるのと同様に返ってくるレスポンスも異なり、ブラウザシナリオでは、外部SAML IdPの種類にかかわらず、ちゃんと利用プロトコルと外部SAML IdPのURLを返してきますが、Azure AD Joinの場合は、外部SAML IdPのURLが返ってこず、ここでレルム探しが失敗、先のエラーメッセージが表示されています。

ブラウザシナリオでのレスポンスの例
{
  "NameSpaceType":"Federated",
  "federation_protocol":"SAML20",
  "Login":"hoge@example.net",
  "AuthURL":"https://idp.example.net",
  "DomainName":"example.net",
  "FederationBrandName":"eIdentity",
  "federation_saml_request":"xxxxx",
  "federation_saml_relay_state":"xxxxx",
  "cloud_instance_name":"microsoftonline.com"
  "TenantBrandingInfo":[{"xxxx"}]
}

Azure AD Joinのレスポンスの例(AD FSの場合)
{
  "Username":"hoge@example.net",
  "Display":"hoge@example.net",
  "IfExistsResult":0,
  "Credentials":{
    "PrefCredential":4,
    "HasPassword":true,
    "RemoteNgcParams":null,
    "FederationRedirectUrl":"https://fs.example.net/adfs/ls/?...omit...",
    "EstsProperties":{"xxx"},
    "apiCanary":"xxx"
  }
}

Azure AD Joinのレスポンスの例(外部SAML IdPの場合)
{
  "Username":"hoge@example.net",
  "Display":"hoge@example.net",
  "IfExistsResult":1,
  "Credentials":{
    "PrefCredential":1,
    "HasPassword":true,
    "RemoteNgcParams":null},
    "EstsProperties":{"xxx"},
    "apiCanary":"xxx"
   }
}

上記のように、外部SAML IdPを使っているとFederationRedirectUrlが返ってこないので、フェデレーション先にリダイレクトがされません。

どこかのタイミングでこの挙動も変わるかも知れませんが、取り合えず現状はAzure AD Joinの計画がある場合は、Azure ADだけでサインインするか、AD FSを含む外部ws-federation IdPとして使う、という2択になりそうです。

2017年5月13日土曜日

[Azure AD] Azure AD B2C に OIDC/SAML 対応の外部 IdP が設定可能に

こんにちは、富士榮@ミュンヘンです。

最近何かと熱い分野でもある CIAM(Consumer Identity and Access Management)ですが、今週ドイツ・ミュンヘンで開催された European Identity & Cloud Conference 2017(EIC)でも他のテーマである GDPR、PSD2 などプライバシー系の法令対応の話や 昨年のニューオリンズで開催された Cloud Identity Summit(CIS)でも大きな話題となった Blockchain による信頼できる Identity 基盤と VRM(Vendor Relationship Management)、Respect Network の文脈での Self Sovrin Identity などと並行して大きく取り上げられていました。

そんな中、平行して US で開催されていた Build ではマイクロソフトの CIAM の実装である Azure Active Directory B2C の大きなエンハンスが発表されました。

ポイントは、カスタムの外部 IdP として

  • OpenID Connect の OP をサポート
  • SAML 2.0 の IdP をサポート
したことです。

これまでは Microsoft Account、Facebook、Google、LinkedIn、Amazon.com、などメジャーなコンシューマ ID プロバイダが正式サポート、twitter や Weibo、QQ、WeChat が Preview として対応、という状況でしたが、OpenID Connect および SAML に対応したことで、自分の好きな ID プロバイダをカスタムで追加することが出来るようになりました。

公式なドキュメントでは OpenID Connect 対応の IdP として Azure AD、SAML 対応の ID プロバイダとして salesforce.com を例として構成例が解説されています。

公式ドキュメント

ガリガリと XML を書いてアップロードする必要があるなど、まだまだ手順が面倒なのですが、公式アナウンスでも次の数週間でもう少し簡単な実装方法に対応させる、とありますのでそちらに期待しましょう。

管理画面の Identity Experience Framework - Preview というものが皆さんの Azure AD B2C にも来ているはずです。この中にカスタムポリシーを構成するための機能が詰まっています。



早速 Azure AD を Azure AD B2C のカスタム IdP として追加してみたのが以下の画面です。

色々とカスタマイズの余地もあるので、引き続き触っていきたいと思います。


2017年5月6日土曜日

[Azure AD]条件付きアクセスの信頼済みネットワークが拡張されてました

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

永らく条件付きアクセスの信頼済みIPの上限数(50レンジ)に悩まされてきた管理者の皆さんに朗報です。(といってもしばらく前に拡張されていたので、既に気が付いた人は使っていると思いますが)

これまでは、旧MFAポータルで信頼済みIPを設定していたのですが、登録可能な数は50レンジまででした。



この上限で困るケースが社内からのネットワークの出口が事業所毎にあったり、クラウドベースのプロキシサービスを使っているようなケースです。

以前、マイクロソフト・コーポレーションの開発チームとのディスカッションの場でもこの制限に関しては私を含め複数の人から改善リクエストが出ており、名前付きネットワーク・オブジェクトとの統合のロードマップが示されていましたが、条件付きアクセスの設定が正式に新ポータルへ移行されたタイミングで信頼済みIPについても移行されました。

尚、現段階では以下の注意点があります。
・過去に作成したアプリケーションの条件付きアクセスの構成は新ポータルからは見えないので、構成し直す必要があります
・再構成しない場合、過去に作成したアプリケーションについては旧ポータルの信頼済みIPが使われます
・新しくアプリケーションを作成する場合、旧ポータルからアプリケーションを作成する場合でも、条件付きアクセスは旧ポータルからは構成できなくなっています。条件付きアクセスの構成は新ポータルから実施してください


早速ですが、構成を見てみます。

新ポータルの条件付きアクセスの構成にNamed Locationsという項目が存在するので、New locationをクリックしてネットワークの場所を定義していきます。

IPレンジをどんどん追加できます。(画面からの直接入力の場合は10個単位で保存をしないとダメですが、保存した後に再度ネットワーク構成を開いて追加していけばどんどん追加できます)また、テキストファイルにネットワークレンジの一覧を書いてUploadすることで一気に追加することが出来ます。


次はこれを使って条件付きアクセスのルールを構成してみます。

まずは対象のユーザ・グループを選択します。ここでは全員を対象としています。


次に対象とするアプリケーションを選択します。ここでは「pharaoh1234」という名前のアプリケーションを対象としています。

次に、条件を設定します。今回信頼済みIPに設定されていないネットワークからのアクセスの場合は多要素認証を要求しようと思うので、ここのLocationsにInclude:All locations、ExcludeにAll trusted IPsを指定します。



条件に一致した場合のアクションとして多要素認証を要求したいので、以下の通りRequire multi-factor authenticationにチェックを入れます。

後は、ルールをEnableにして保存すると完了です。


この状態で信頼済みIP以外のネットワークからアプリケーションにアクセスすると以下のように多要素認証が要求されます。



2017年4月29日土曜日

[MIM]3月のアップデートでサポートプラットフォームの大幅な改善+α

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

色々と追い付いていなかったので、改めてまとめておきます。

3月にMicrosoft Identity Manager 2016 SP1 (MIM)向けのホットフィックスがリリースされ、特にサポートされるプラットフォームが大幅に追加されました。

個人的には、プラットフォームサポート周りでは「SQL Server 2016 Always Onのサポート」が非常に熱いトピックスでしたが、他にもSCSM 2016がサポートされたり、Visual Studio 2017が使えるようになったり、など色々とエンハンスが行われています。

MIM 2016でサポートされるプラットフォーム一覧
https://docs.microsoft.com/en-us/microsoft-identity-manager/plan-design/microsoft-identity-manager-2016-supported-platforms


他にも以下が新しく使えるようになった代表的なシナリオです。



こちらからダウンロード可能なので、MIM使いの皆さんは適用しておきましょう。

2017年4月18日火曜日

今年の de:code はユーザ事例を通して Azure AD 導入の実情をお伝えします

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

いつの間にか de:code 2017 まで約1か月となりました。
昨年の de:code ではチョークトークで何でも QA コーナーみたいなセッションを担当しましたが、今年は本職?での株式会社アシックス様の案件事例を通して Azure AD の活用の実際をお伝えします。



これまでも事例をベースにしたセッションはやってきたんですが、実は Azure AD 案件の事例をオープンな場でお話しするのって初めてなんですよね。今回は Azure AD を導入するにあたり Azure Web App や Azure Automation、Express Route など Azure 関連のサービスをそれなりの種類使っていたりしますので、Azure AD 自体の使い方に加えて、その辺りの話も織り交ぜつつグローバル企業におけるクラウド・ベースの認証基盤のあり方や既存環境からのマイグレーションなどについてお話できると良いなぁ、と思っています。

参考)これまでオープンにしてきた IdM 系の事例です。(節操なく色んなベンダの仕事してますね)



どうしても本職絡みだと言えないこともあったりするんですが、今回はなるべく Azure AD の各種技術的な要素が実際の案件ではどのように使われているのか?を皆さんにお伝えすることで、色々とイメージをしてもらえればと思いますので、お手すきの方はぜひお越しください。

あ、2日目の最終コマだったと思います。


尚、今回の de:code ではセキュリティ・トラックが 16 セッションもあり、私の他にも Enterprise Mobility の MVP が大勢出てきてマイクロソフト社員が語れないこと?を語ってくれると思いますので、私自身も非常に楽しみです。

以下、セキュリティ・トラックのセッション一覧です。

セッション番号タイトル担当
SC01DevSecOps on Azure : セキュリティ問題に迅速に対応するためのパイプライン設計MS安納さん
SC02シチュエーション別 Active Directory デザインパターンMVP宮川さん
SC03Active Directory の DR 対策~天災/人災/サイバー攻撃、その時あなたの IT 基盤は利用継続できますか?MVP渡辺さん
SC04あなたのサービスを "ID" で守る! Azure Active Directory の条件付きアクセスの基礎と実装MS松井さん
SC05株式会社アシックス様における Azure AD 導入プロジェクトの実際MVP富士榮
SC06Windows と Azure、2つの Information Protection をディープに解説!MVP国井さん
SC07Azure AD と Ruby で学ぶ OpenID Connect!MVP真武さん(nov)
SC08SDL からビジネスモデルまで IoT セキュリティを俯瞰するMS高橋さん
SC09パッチ待ちはもう古い!Windows 10 最新セキュリティ技術とゼロデイ攻撃攻防の実例MS村木さん
SC10Intune Application Protection を可能にするモバイル アプリ開発MSロバートさん
SC11セキュリティマニアックス ~侵入。ダメ。ゼッタイ。~MS蔵本さん
SC12DevSecOps 時代のセキュリティ人材DIT河野さん
SC13ログ管理で向上させるセキュリティMS山本さん
SC14IoT のセキュリティアーキテクチャと実装モデルMS安納さん
SC15Windows Hello で実現するハイブリッド 生体認証MS小町さん
SC16スパムの脅威から企業を守る!Office 365 で実現するセキュアコラボレーションtwofive末政さん


ちなみに、今年はゴールデンウィーク明けの EIC(European Identity & Cloud Conference 2017)に行こうと思っているので、実はほとんど資料を作る時間がないのが最大の課題です・・・。



2017年4月5日水曜日

Office365管理者は要対応)UPNとProxyAddress重複オプションの強制変更がいよいよ開始

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

以前紹介したAzure AD Connectでのディレクトリ同期時にUPNやProxyAddressが重複しないように自動的にサフィックスをつけてくれるオプションがいよいよ全テナントで強制的に有効になるようです。

 以前の紹介記事
 [Azure AD/Office365]管理者は要注意。ディレクトリ同期に関する仕様変更
 http://idmlab.eidentity.jp/2016/09/azure-adoffice365.html

簡単に内容をリマインドしておくと、複数のオンプレミスADから単一のAzure ADディレクトリへ同期したり、オンプレミスのUPN以外の属性(例えばメール属性)をAzure ADのUPNにマッピングするなど属性のユニーク性が担保されない環境で運用を行う際、ディレクトリ同期時にAzure AD側でUPNを自動的に「ユーザ名+4桁のランダム数値@デフォルトドメイン名」という様に変更する、というオプションが追加されました。
(UPN版とProxyAddress版の2つのオプションがあります)

このオプションが有効だとディレクトリ同期時の重複エラーを抑制することはできますが、勝手にUPNが書き換わってしまうのでオンプレミスのディレクトリの状態によっては若干困ることがあるので、昨年発表された段階では強制的に有効化されることはなく、しばらくは猶予期間が作られました。

しかし、この4月から遂に強制変更が開始されるようです。

4月1日前後に以下のメールが管理者宛てに来た場合は、メールに記載の日程から強制的に有効化されます。私のテナントの場合は4/19から強制有効化されるようです。
(以外と急でした・・・)

タイトル:New Identity Synchronization Feature Being Enabled - Duplicate Attribute Resiliency
差出人:MSOnlineServicesTeam@microsoftonline.com




急ぎ、自社のディレクトリ構成を確認してUPNが急に変わった~~~というようなパニックに陥らないように準備しておきましょう。




2017年3月29日水曜日

[Azure AD+PingAccess]Basic認証のあるバックエンドサイトへアクセスする

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

前回はAzure ADとPingAccessの組み合わせで、PingAccessのバックエンドに配置したHTTPヘッダ認証のサイトをAzure AD Web Application Proxy(Azure AD WAP)で公開する構成を紹介しました。

PingAccessは色々と器用なツールなので、既存のアプリケーションがBasic認証だった場合にも「ある程度」対応ができます。今回はPingAccessのバックエンドのサイトがBasic認証で構成されている場合の設定を紹介します。

尚、「ある程度」と書いたのはBasic認証がユーザのIDとパスワードをエンコードしたものを認証ヘッダにつけるという仕組みである以上、Password Vaultingをしないといけないので、固定のIDとパスワードしか投げ込むことしかできず、個別のユーザ認証とはならない為です。

では、早速。

◆サイトを用意する

何はともあれ、Basic認証を要求するサイトを作ります。今回はIISで構成しました。
PingAccessのサーバからアクセスしてBasic認証が要求されることを確認しておきます。


◆PingAccessのSite Authenticatorを作成する

SitesメニューよりSite Authenticatorを作成します。

TYPEにBasic Authentication、USERNAMEとPASSWORDにBasic認証に使うユーザ名とパスワードを設定します。
ここが微妙なところで、個別のユーザ毎ではなく、Authenticator単位での設定しかできないので、実際のサイトへアクセスするユーザ名とパスワードが共通になってしまいます。

◆SiteにAuthenticatorを紐づける

Authenticatorを作ったらSiteに紐づけます。既存サイトであれば構成を編集して、新規サイトなら追加をして、SITE AUTHENTICATORSに先に作成したSite Authenticatorを設定します。

その他の設定は前回行ったものと同じなので、詳細は省略します。

◆Azure AD WAP経由でアクセスする

Azure AD WAP、PingAccessを経由せずにアクセスするとBasic認証が要求されましたが、Azure AD WAPを経由してアクセスするとBasic認証はかからずにサイトへログオンできます。

Webサーバのログを見ると、先ほど設定したユーザでWebアクセスがあったことがわかります。



今回はここまでです。せっかく色々な機能があるPingAccessなので、上手に連携していけば既存のオンプレミスのアプリケーションのAzure ADへ対応させる新たな構成の選択肢となってくる可能性もありますので、今後も目が離せませんね。

2017年3月27日月曜日

[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版ポータルは
 もしくは、
 あたりからアクセスできます。

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へシームレスに移行する際には本領を発揮することになると思います。

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