2015年5月20日水曜日

[FIM/MIM]CTP4へのインプレースアップデート(Sync Engine編)

4月下旬にconnectサイトにリリースされたMicrosoft Identity Manager 2016 CTP4ですが、今回のバージョンからインプレース・アップデートに対応しています。
※現状FIM CMについてはバグがありアップデート出来ないようですが。

参考)
 [MIM]新しいPublic Previewがリリース、MIM2016へ
 http://idmlab.eidentity.jp/2015/04/mimpublic-previewmim2016.html

今回はSynchronization Serviceのインプレース・アップデートを行ってみます。

◆結果
今のところ何の問題もなく、HotFixを適用するのと同じ程度の手間でアップデートが出来ました。
(特にSyncエンジンは殆ど何も変わっていないので、当たり前ですが)
また、ECMA2で作成したGeneric REST MAについても簡単な確認をした限りでは問題なく使えていそうです。


◆アップデート手順
まず、アップデート前のバージョンを確認しておきます。


2つ前のHotFixが適用されたForefront Identity Manager 2010 R2 SP1(FIM2010R2)ですね。

早速connectからダウンロードしたCTP4を解凍し、Synchronization Serivceフォルダ以下のsetup.exeを実行します。



ちゃんとUpdateとして認識してくれているようです。



まだ、バージョン番号がMicrosoft Identity Manager 2015のままですね。



アップデートなので基本的な設定は引き継いでくれます。




色々と注意事項がでますがセットアップを継続です。




セットアップはすぐに終ります。
特に問題なくセットアップフェーズは進みました。


◆確認
早速Synchronization Managerを起動します。


起動時のロゴがMicrosoft Identity Managerになっていますね。

しかし、バージョン情報を見ると相変わらずFIMのままです。
ビルド番号は流石に4.1.1790.0と新しくなっていますが。

この状態で簡単に管理エージェントを動かしてみましたが、特に問題なく動きました。


ここまでです。Synchronization Serviceについては何の問題もありませんでした。

次回はFIM Servive/Portalのアップデートをやってみまたいと思います。
(こちらはそれなりに変な動きをしてくれています。流石にモジュール構成の変更が多いので難しい部分だったのだと思います)




2015年5月12日火曜日

[Build 2015]アイデンティティ関連セッションリスト

4月~6月にかけて海外では各種イベントが続々と開催され、アイデンティティに関しても新しい情報が出てきたりするので目が離せません。

・Microsoft
 Build 2015
 http://www.buildwindows.com/

 Ignite 2015
 http://ignite.microsoft.com/

・Kuppinger Cole
 Europian Identity & Cloud Conference 2015(EIC 2015)
 https://www.id-conf.com/

・Ping Identity
 Cloud Identity Summit 2015
 http://www.cloudidentitysummit.com/


今回は先日サンフランシスコで開催されたMicrosoftのBuild 2015よりアイデンティティ関連のセッションをピックアップしました。
スライドとビデオが公開されているので、Azure Active Directory(AzureAD)、Office365 API、Windows 10のPassport/Windows Hello関連に興味のある方は必見です。

◆AzureAD連携アプリケーション開発関連
Azure Active Directory: Identity Management as a Service for Modern Applications
http://channel9.msdn.com/Events/Build/2015/2-738

Cloud Authentication Troubleshooting and Recipes for Developers
http://channel9.msdn.com/Events/Build/2015/2-740

Develop Modern Web Applications with Azure Active Directory
http://channel9.msdn.com/Events/Build/2015/2-753

Develop Modern Native Applications with Azure Active Directory
http://channel9.msdn.com/Events/Build/2015/2-769


◆AzureADとOffice365 API関連
Get Your Hands Dirty with the Office 365 APIs, Authentication and SDKs
http://channel9.msdn.com/Events/Build/2015/4-630


◆Passport/Windows Hello関連
Single Sign-On with Secure Authentication
http://channel9.msdn.com/Events/Build/2015/2-709

Managing Mobile Devices and Applications in an Enterprise
http://channel9.msdn.com/Events/Build/2015/3-654

Microsoft Passport and Windows Hello: Moving Beyond Passwords and Credential Theft
http://channel9.msdn.com/Events/Build/2015/2-639

Building Universal Windows Apps with Office 365 APIs
http://channel9.msdn.com/Events/Build/2015/3-767

App-to-App Communication: Building a Web of Apps
http://channel9.msdn.com/Events/Build/2015/3-765



尚、セッションデータを一括ダウンロードするスクリプトが公開されているので、上手く活用をして効率的にマテリアルをダウンロードすると良いでしょう。
https://gallery.technet.microsoft.com/All-Videos-and-Slides-from-64a86489


ちなみにこのスクリプト(というよりもChannel9のRSSフィード)には不具合があり、一部修正が必要です。

以下のステップで修正をします。
1.RSSフィードを直接ダウンロードする
  以下のURLをブラウザで直接開いて表示された内容を保存します。
  http://channel9.msdn.com/Events/Build/2015/RSS/slides


2.ダウンロードしたフィードを修正する
  1287行目のitunes:summaryの行に不具合があるので、この行を丸ごと消してしまいましょう。


3.スクリプトがローカルにダウンロード・修正したRSSフィードを読み込むように修正する
  ダウンロードしたスクリプトがインターネット上のRSSフィードではなく、上記2で修正したフィードを読み込むように以下の様に修正します。
  (修正前)


  (修正後)


後は保存してPowerShellを実行すればごっそりファイルのダウンロードが出来ます。
※スライドだけでも1.7GBくらいあるので空き容量に注意が必要です。

2015年5月10日日曜日

[Windows10]デバイス&サービス間のシングルサインオンの仕組み

※ご注意
・現在公開されている情報+Fiddler等でWindows10の動きを解析した結果からの推測です。
 (そのうちMSDNあたりに確かな情報も公開されると思います)
・Windows10 Insider Preview(Build 10074)をベースに確認しています。
・細かい話は今月末(5/27)に開催されるidcon(別名fidcon)で話をする予定です。



今回はこれまで紹介してきたWindows10のクラウド・ドメイン参加(Cloud Domain Join/CDJ)によるPCログオンとOffice365等のアプリケーションの間のシングルサインオンの動作の仕組みについて考えてみます。

その前におさらいです。

◆CDJとは
簡単にいうと、Windows10のデバイス(PC)へのログオンにAzure Active Directory(AzureAD)を使う、つまりオンプレミスのActive Directoryへのドメイン参加ではなく、クラウド上のAzureADへドメイン参加する機能のことです。

<関連ポスト>
 [Windows10/AAD]クラウド・ドメイン参加を試す
 http://idmlab.eidentity.jp/2015/02/windows10aad.html

 [Windows10/AAD]OOBEでクラウド・ドメイン参加
 http://idmlab.eidentity.jp/2015/03/windows10aadoobe.html


◆CDJを使ったTrue SSOとは
これまでWebアプリケーション間のSSOはAD FSやAzureADなどSAMLやws-federationの実装により割と容易に実現出来ました。また、社内のPCの様にActive Directoryドメインに参加している環境においてはAD FSへの統合Windows認証をすることによりPCログオンとWebアプリケーションとの間でのSSOを実現してきました。
しかし、あくまで統合Windows認証に依存する仕組みのため、社外からのアクセスなどドメイン・ネットワークの境界を超えると途端にSSO出来なくなる、という非常に限定的な仕組みでもありました。


しかし、CDJを使いPCログオンをAzureADで行うことによりドメイン・ネットワークの境界の外にある社外PCについてもPCログオンとWebアプリケーションのSSOを実現することが出来るようになりました。


<関連ポスト>
 [Windows10/AAD]Technical Preview Build 10041のCDJでOffice365とのSSOを実現
 http://idmlab.eidentity.jp/2015/03/windows10aadtechnical-preview-build.html

 ※ちなみにBuild 10074ではOffice365とのSSOは上手く動かず、代わりにAzureの新管理ポータル(https://portal.azure.com/)へSSO出来るようになっています。



さて、本題です。
では、CDJを使いWindows10のPCではどのようにデバイスとアプリケーションの間のSSOを実現しているのでしょうか?

CDJではざっくり言うと以下の処理が実行されます。
①AzureADへのデバイス登録
 ⇒秘密鍵のダウンロード、TPMへの保存
②ユーザ認証
 ⇒秘密鍵を使ってAzureADからプライマリ・リフレッシュ・トークン(PRT)の取得
③アプリケーションへのアクセス
 ⇒AzureADでPRTをアクセス・トークンへ交換し、アプリケーションへ提示

PINや顔認証でPCにログインできるようになるのは、CDJでAzureADの信頼済みデバイスとして登録された後、TPM上にストアされた秘密鍵にアクセスすることが出来ることでユーザを認証することが可能なためです。
(この秘密鍵にアクセスするためのパスフレーズとしてPINやバイオメトリクスを使っているのが噂のWindows Helloです)


このあたりは、先日のJapan SharePoint Groupでデモを交えつつ話をした内容です。
当日のスライドはこちら。後半でNext Generation Credentials/NGC(現在はPassportって言ってるやつです)のフローを解説しています。



特にこの辺のスライドですね。


で、実際SSOを実現するには、この中で出てくるPRTをアプリケーション向けのアクセス・トークンに交換する必要がありますが、この部分を担当しているコンポーネントがWindows10から導入された「Web Account Manager」および「AAD Token Broker Plugin」です。

Web Account Managerは現在.NETやJava Script向けに提供されているActive Directory Authentication Library(ADAL)の後継(?)となるコンポーネントで、バックエンドで認証やアクセストークンの取得などの処理を行うものです。ただ、ADALが各アプリケーションに組み込むライブラリとして提供されていたのに対して、Web Account ManagerはWindows10/Windows Phone10に組み込まれた独立したモジュールとなっています。

OpenID ConnectのRPとして実装されたWebアプリケーションは、AzureAD上に登録する必要があり、登録の際のredirect_uriに「ms-appx-web://Microsoft.AAD.BrokerPlugIn/[アプリケーションのsid]」を指定することでWeb Account Managerを呼び出すことが出来ます。(ネイティブアプリケーションからはRequestTokenAsyncなどのAPI経由で呼び出します)

Build 2015のセッションより


単純にWeb Account Managerを使うだけだとAzureADで個別に認証をしてアクセス・トークンを受け取る必要がありますが、先にCDJで取得したPRTがあると、AAD Token Broker PluginがPRTをAzureADへ渡してアクセス・トークンを取得するのだと思われます。

これで、PCへのログオンとWebアプリケーションへのログオンのSSOの出来上がりとなります。


ちなみにAzureAD上にリソースとして登録していないWebサイトからの認証要求が来ると、AADのイベントログにID1098、1097が記録されるので、PRTの交換に失敗していることがわかります。




一番上にも書きましたが、5/27のidconでもう少し深く仕組みの紹介をしたいと思います。
※CDJの各フェーズで実際にどのような通信が発生しているのかをfiddlerで可能な限り取得した結果などもお見せできれば、、と思います。仕組み上、ログイン中に発生している通信も多いので、全部がトレースできる訳ではありませんが。。。

2015年5月9日土曜日

[AD FS]Windows Server Technical Preview 2のAD FSファーストレビュー(管理GUI編)

先日第2弾が公開された次期Windows ServerのTechnical PreviewのAD FSがどう変わったのか確認してみたいと思います。

第一印象ですが、かなり便利・かつ高機能になっている印象です。

私なりのポイントですが、以下の5点だと思います。(まだ触り切れていないのでどこまで使えるかは微妙ですが)

  1. PowerShellでしか出来なかった操作がかなりの範囲でGUIで操作できるようになった(OAuthのクライアント登録とかScope登録とか)
  2. OpenID Connect Discoveryに対応した(限定的ではありますが)
  3. Microsoft Azure MFAが最初から組み込まれた
  4. VPNアクセス用の証明機関としての機能が付いた(?)
  5. Web Application Proxyの管理GUIが統合された(?)

※?マークはそれっぽいメニューが存在するだけなので、どう動くのかはまだわかっていません。

また、結局Blogには投稿できませんでしたが、前回のPreviewから

  • OpenID Connectへの対応
  • OAuth2.0への対応の改善(Implicit、Client Credentialへの対応)

がなされています。
(検証結果をまとめている時間がなかっただけなので、まとめたら改めて公開したいと思います)


ということで今回は管理ツール周りを見ていきたいと思います。

◆メニュー構成
管理GUIの左ペインを見ると以下の5項目でメニューが構成されています。

  • Service
  • Access Control Policies
  • Relying Party Trusts
  • Claims Provider Trusts
  • Clients



Windows Server 2012R2では

  • サービス
  • 信頼関係
  • 認証ポリシー

の3項目でした。
サービスはそのまま、以前は信頼関係メニューの中にあったRelying Party Trust(証明書利用者信頼)とClaims Provider Trusts(要求プロバイダー信頼)がトップレベルに昇格、Access Control PoliciesとClientsが新規に追加され、認証ポリシーが消えた、という感じです。

では、それぞれ順番に見ていきます。


◆Serviceメニュー
以下の9項目のサブメニューで構成されています。

  • Attribute Store
  • Authentication Methods
  • Certificate Authority
  • Certificates
  • Claim Descriptions
  • Device Registration
  • Endpoints
  • Scope Descriptions
  • Web Application Proxy



それぞれ簡単に解説しておきます。
  • Attribute Store
  • 以前は信頼関係の配下にあったものが移動されています
  • Authentication Methods
  • 以前はトップメニューにあった認証ポリシーがServiceの配下に来ています
  • Certificate Authority 
  • 新規に追加された項目です。VPNアクセス用の証明書の発行をする機能のようです。




    • Certificates
      • 変化なしです。
    • Claim Descriptions
      • 変化なしです。
    • Device Registration
      • 新規に追加されています。Windows Server 2012R2ではPowerShellで設定していたものがGUIで出来るようになっています。(前回のPreviewより)
    • Endpoints
      • 変化なしです。
    • Scope Descriptions
      • 新規に追加されています。OAuth/OpenID ConnectのScope設定が出来ます。これも以前はPowerShellで設定していたものがGUIで出来るようになっています。

    • Web Application Proxy
      • 新規に追加されています。WAPを構成した場合にここで管理できるようになるのかも知れません。




    ◆Access Control Policiesメニュー
    新規に追加されたメニューです。
    これまでClaimルールで頑張って書いていたような認可ポリシーがある程度テンプレートとして用意されています。



    ◆Relying Party Trustsメニュー
    あらかじめ以下のRelying Partyが定義されています。

    • VPN Server(無効化状態)
    • UserInfo




    Windows Server 2012R2ではここにDevice Registration Serviceが登録されていましたが、初期状態では存在しません。
    また、ここにはSAMLやws-federationのRelying Partyだけではなく、OAuthの保護リソースも登録されるため、OpenID ConnectのUserInfoがここに最初から登録されています。


    ◆Claims Provider Trustsメニュー
    ここは何も変わりません。初期値ではActive Directoryだけが登録されています。



    ◆Clientsメニュー
    新しく出来た項目です。
    ここで、OAuthのクライアント管理を行うことが出来ます。
    ちなみに、Windows Server 2012R2ではPublic Clientしか登録することが出来ませんでしたが、次期バージョンからはConfidentialも登録できるようになっています。(つまり、client_secretの発行が出来、Client Credentialなどのフローで使えます)



    初回なので、今回はここまでにしておきますが、次回以降でもう少し細かい部分や動きを確認していきたいと思います。

    【参考】
     Windows Server Technical Preview 2のISOファイルやVHDファイルは以下よりダウンロードできます。
      https://technet.microsoft.com/ja-jp/evalcenter/dn781243.aspx
     ※もしくはMicrosoft Azure上で仮想マシンとしての提供されていますので、そちらを使うことも可能です。
      今回は手元にISOファイルから新規インストールしました。

     尚、最初に公開されたバージョンのTechnical PreviewのAD FSについては以下のポストで紹介しています。
     [AD FS]Windows Server Technical Previewで追加された機能~PowerShell編
      http://idmlab.eidentity.jp/2015/03/ad-fswindows-server-technical.html
     [AD FS] Windows Server Technical PreviewのAD FSを試す
      http://idmlab.eidentity.jp/2014/10/ad-fs-windows-server-technical.html

    2015年5月6日水曜日

    [FIM]最新HotFixでPCNSがようやくWindows Server 2012 R2に対応

    ようやくPCNS(Password Change Notification Service)がWindows Server 2012 R2のドメインコントローラに対応しました。

    これでPCNSがネックでドメインコントローラをWindows Server 2012 R2へアップデート出来なかった人たちも一安心です。(どれだけいるかは・・・ですが)

    ちなみにPCNSは、Active Directoryドメイン上の全ドメインコントローラ上にインストールするモジュールで、各PCや管理者によるActive Directoryのパスワード変更をフックしてFIMに通知・連携するためのモジュールです。これを使うとctrl+alt+delなどで変更したパスワードをFIMと連携している他のアプリケーションへも連携することが出来ます。

    今回のForefront Identity Manager(FIM)のHotFixでは実際にPCNSのモジュールが更新されているわけではなく、FIMに同梱されているActive Directory Management Agentが更新されているところを見ると、これまでもWindows Server 2012 R2からのパスワード変更通知は受け取れていたようですが、(おそらくパスワード自体の)ハンドリングが上手く出来ていなかった、というあたりを改修したように思われます。
    (パッチのリリースノートを見ても、PCNSからの通知をFIM Synchronization Serviceが受け取った際のLsaLookupNames2 APIをコールする際のドメイン・フォーマットに起因する不具合の修正が含まれていますので、このあたりがWindows Server 2012 R2対応した部分だと思われます)

    他にもFIM Sync/FIM CM周りでも修正は入っているようなので、現在FIM 2010R2 SP1を運用している方は早めの適用が推奨されています。


    ◆前提/注意事項
    と、ここまで書きましたが、今回のHotFix適用にあたり、以下の注意事項があります。

    1. Windows Server 2012 R2に対応したのはあくまで「PCNS」
      • ⇒FIMを導入するサーバはWindows Server 2012無印までしか対応していません。MIMを待ちましょう。
    2. カスタムの管理エージェントを導入している人は互換性に関する不具合が出ることがあります。
      • 管理エージェントをコンパイルした時のMicrosoft.MetadirectoryServicesEx.dllのバージョンによってはno-start-maエラーが出る場合があるので、その場合は.configファイルにバージョン互換に関する記載を追記しましょう。詳細はHotFixのダウンロードページに記載されています。
      • ちなみに私の環境では拙作Generic REST API Management Agentは何もしなくても問題なく動きました。


    - HotFixダウンロードページ
     https://support.microsoft.com/en-us/kb/3048056
    - HotFix適用によるビルド・バージョン
     FIM : 4.1.3634.0
     BHOLD : 5.0.2959.0

    2015年4月30日木曜日

    [Azure/SAML]Azure Webアプリにお手軽テスト用SAML SPをデプロイする

    Azure Active Directory(AzureAD)やActive Directory Federation Service(AD FS)を始めとしたSAMLに対応したIdentity Provider(IdP)を構築すると、どうしても必要になるのがテストに使うアプリケーション(Service Provider/SP)です。

    個人的には設定が超お手軽なGoogle Appsをテスト用SPとして使ったりすることが多いのですが、もう少し簡単なアプリケーションが欲しいなぁ、、と思うことも多くオンプレの環境にはPHPアプリケーション用のPHPライブラリであるSimpleSAMLphpをセットアップしてあったりします。
    ※WIFとかADALがちゃんとSAMLを喋れればいいんですが、ws-federation/OpenID Connectなんで実はSAML SPってぽっかり穴が空いています。

    今回はもう少しお手軽にいつでも試せる環境を、ということでAzure WebアプリにSimpleSAMLphpをデプロイしてみます。

    尚、考えることはみんな一緒で日本マイクロソフトの松崎さんも同じようなことを考えていらっしゃったようです。
    http://blogs.msdn.com/b/tsmatsuz/archive/2014/01/30/azure-ad-and-php-application-sso-federation-using-simplesamlphp.aspx

    松崎さんがblogを書かれた段階ではAzure WebsiteにはうまくSimpleSAMLphpが導入できなかった様なのですが、現在は割と素直に導入できました。


    では、さっそくやってみます。

    ◆Azure Webアプリ(WebSite)の作成

    ギャラリーから空のサイト(PHP)を選択し、Webサイトを作成します。



    ◆SimpleSAMLphpのダウンロードと展開

    以下のURLから最新のSimpleSAMLphpをダウンロードし、ローカルの任意のフォルダにtar.gzを展開します。

     SimpleSAMLphp
     https://simplesamlphp.org/


    ◆Azure Webアプリへのデプロイ

    Azureへのデプロイ方法はFTPなど色々とありますが、今回は先ほどモジュールを展開でぃたフォルダをGitのローカルレポジトリに設定してデプロイしました。

    まずは、作成したWebアプリの「ソース管理の統合」メニューの「ソースコードの位置」で「ローカルGitレポジトリ」を選択します。



    そして、ローカルのGitレポジトリを設定します。
    ※Gitクライアントなどのセットアップ方法は省略します。

    Git Bashでモジュールを展開したフォルダへ移動し、以下を打ち込みます。
    git init
    git add .
    git commit -m "initial commit"
    git clone https://naohiro@samlsp1.scm.azurewebsites.net:443/samlsp1.git
    git remote add azure https://naohiro@samlsp1.scm.azurewebsites.net:443/samlsp1.git
    git push azure master
    


    これでモジュールがAzure上にデプロイされました。


    ◆仮想ディレクトリの設定

    デプロイしたモジュールへ外からアクセスするための仮想ディレクトリを設定します。
    SimpleSAMLphpでは/simplesamlという仮想ディレクトリに[展開先]/simplesamlphp/wwwをマッピングする必要がありますので、以下のような仮想ディレクトリを設定します。


    ◆SimpleSAMLphpへのSP登録

    テスト用なのでデフォルトで登録されているSPを使います。
    SP設定は[展開先]/config/authsources.phpファイルに存在するので、ローカルで対象ファイルを編集します。
    ファイルの中に'default-sp'というブロックがあるので、その中を修正します。

    変更点は、以下の3点です。

    • entityID : 何でも構わないんですが、一般にSPのURLを設定するので、「http://samlsp1.azurewebsites.net」の様に設定しました。
    • idp:ここは設定しなくても良いのですが、デフォルトで使うIdPとしてPingIdentityのPingOneを使いたかったので、PingOneの自分のテナントのURLを指定します。
    • NameIDPolicy:SimpleSAMLphpは初期値でtransientが設定されるので、何が来ても良いようにNULLにしておきます。


    こんな感じで設定しました。
    'default-sp' => array(
            'saml:SP',
    
            // The entity ID of this SP.
            // Can be NULL/unset, in which case an entity ID is generated based on the metadata URL.
            'entityID' => 'http://samlsp1.azurewebsites.net',
    
            // The entity ID of the IdP this should SP should contact.
            // Can be NULL/unset, in which case the user will be shown a list of available IdPs.
            'idp' => 'https://pingone.com/idp/xxxxxx',
    
            // nameid
            'NameIDPolicy' => NULL,
    



    ローカルでauthsources.phpを更新したので、GitでAzure上へデプロイしておきます。
    git add --all
    git commit -m "sp config"
    git push azure master
    


    この段階で念のためAzure Webアプリの再起動をしておきましょう。


    ◆IdP(PingOne)へのSP登録

    今回はテスト用IdPとしてPingOneを指定しました。

    まずは先にSimpleSAMLphpの管理ページにアクセスし、[連携]タブより登録したSPのメタデータを取得します。

    http://samlsp1.azurewebsites.net/simplesaml/
    という形でsamplesamlという名前で作成した仮想ディレクトリへアクセスするとSimpleSAMLphpの管理画面が開きますので、[連携]タブよりメタデータを表示を選択するとメタデータのURLが表示されるので、このURLをメモしておきます。後でこれをPingOneに設定するので。




    次にPingOneの管理コンソールにアクセスします。

     PingOne管理コンソール
     https://admin.pingone.com/

    この[Application]タブを開くとアプリケーションの追加が出来ます。
    [Add Application]より[New SAML Application]を選択しアプリケーション名、説明などを設定して行きます。
    重要なのは、先のSPメタデータを[Upload Metadata]に指定することと、SAML Metadataの項目でIdP側のメタデータをダウンロードしておくことです。





    またSAML Assertionに含める属性とPingOneのレポジトリ内の属性とのマッピングを設定することも可能です。



    これでIdPの設定は終わりです。



    ◆SPへのIdP登録

    再度SimpleSAMLphpの管理画面を開き、[連携]メニューより[XMLをsimpleSAMLphpメタデータに変換]を選択し、先ほどダウンロードしたPingOneのIdPメタデータをSimpleSAMLphp用の設定ファイルへ変換します。


    メタデータパーサにダウンロードしたIdPメタデータを張り付けて[パース]をクリックするとSimpleSAMLphpに設定する内容が表示されます。


    ここで出来上がった設定をローカルの[展開先]/metadata/saml20-idp-remote.phpのphpタグの間に貼り付け、保存して先ほどと同じようにgit pushし、Azure Webアプリを再起動します。


    ◆動作テスト

    これで設定は完了ですが、すこしわかりやすいアプリケーションを作ってSAML Assertionの中身を見えるようにしてみます。
    基本は松崎さんのblogに上がっているphpアプリケーションでモジュールのパスを変えただけです。

    <?php
      require_once("simplesamlphp/lib/_autoload.php");
      $as = new SimpleSAML_Auth_Simple('default-sp');
      $as->requireAuth();
      $attributes = $as->getAttributes();
    ?>
    <div style="font-weight: bold;">Test SAML SP</div>
    <table border="1">
    <?php  foreach ($attributes as $key => $value): ?>
      <tr>
        <td><?=$key;?></td>
        <td><?=$value[0];?></td>
      </tr>
    <?php endforeach;?>
    </table>
    


    これをローカルの[展開先]ディレクトリ直下にindex.phpとして配置し、git pushします。


    これで、アプリケーションも含めすべての準備が整いました。
    早速アプリケーションにアクセスすると、PingOneのログイン画面が表示されるのでログインすると、アプリケーションが表示されます。



    多少手間ではありますが、これで無償で常時稼働出来るSAML SPが完成しました。
    設定もgitで管理できるので新しいIdPを作った際に少し修正して、戻して、、といったことが簡単に出来るようになります。