[SharePoint]JPSPSフォローアップ：認証設定①～フォームベース認証

先日（5/18）に Japan SharePoint Group （http://jpsps.com/）さんの定例勉強会にお邪魔して SharePoint のアイデンティティ管理の話をしてきました。

当日の資料はこちら

Share point における id管理と認証・認可 from Naohiro Fujie

当日は時間もなかったので、簡単なデモを見せることしか出来なかったので、環境の構築の方法について解説しておこうと思います。

まずは、認証の設定についてです。
当日はフォームベース認証と SAML トークンベース認証の2つのデモをお見せしましたが、今回はフォームベース認証について解説します。（Active Directory を LDAP の認証データベースとして利用します）

認証の設定を行い、実際にサイトを利用するには、大まかに以下の手順が必要です。
１．認証プロバイダの作成
２．Web アプリケーションの認証プロバイダの設定
３．Web アプリケーションのユーザーポリシーの設定
４．ユーザープロファイルとの紐づけ設定
５．動作確認 では順番に手順を解説します。

１．認証プロバイダの作成

　この手順では、SharePoint Server が認識する認証プロバイダを作成します。フォームベース認証の場合は、以下の3つの Web サイトの web.config ファイルの編集を行う必要があります。
 　- サーバの全体管理（SharePoint Central Administration v4）
 　- Security Token Service（SharePoint Web Services - SecurityTokenServiceApplication）
 　- 対象の SharePoint Web アプリケーション（作成した名前）
 　　※括弧内は IIS マネージャより見える Web サイトの名前

　IIS マネージャより上記それぞれの Web サイトに対応するフォルダを開き、 web.config を編集します。対象の Web サイトを右クリックしてエクスプローラを開いたところにある web.config が編集対象です。

　各 Web サイトの web.config を以下の用に設定します。

 　- サーバの全体管理（SharePoint Central Administration v4）

 　・<system.web> セクションの以下をコメントアウト

    <roleManager>
      <providers>
      </providers>
    </roleManager>
    <membership>
      <providers>
      </providers>
    </membership>

　・以下を追記

<membership defaultProvider="AspNetSqlMembershipProvider">
      <providers>
        <add name="LDAPMember"
             type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
             server="ADサーバ名.xxx.xxx"
             port="389"
             useSSL="false"
             userDNAttribute="distinguishedName"
             userNameAttribute="sAMAccountName"
             userContainer="OU=フォームベース認証するユーザを入れるOU,DC=xxx,DC=xxx"
             userObjectClass="person"
             userFilter="(ObjectClass=person)"
             scope="Subtree"
             otherRequiredUserAttributes="sn,givenname,cn" />
      </providers>
    </membership>
    <roleManager enabled="true" defaultProvider="AspNetWindowsTokenRoleProvider" >
      <providers>
        <add name="LDAPRole"
             type="Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
             server="ADサーバ名.xxx.xxx" 
             port="389"
             useSSL="false"
             groupContainer="OU=フォームベース認証するユーザを入れるOU,DC=xxx,DC=xxx"
             groupNameAttribute="cn"
             groupNameAlternateSearchAttribute="samAccountName"
             groupMemberAttribute="member"
             userNameAttribute="sAMAccountName"
             dnAttribute="distinguishedName"
             groupFilter="((ObjectClass=group)"
             userFilter="((ObjectClass=person)"
             scope="Subtree" />
      </providers>
 </roleManager>

　- Security Token Service（SharePoint Web Services - SecurityTokenServiceApplication）

 　・<Configuration>セクションに以下を追記

<system.web>
    <membership>
      <providers>
        <add name="LDAPMember"
             type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
             server="ADサーバ名.xxx.xxx"
             port="389"
             useSSL="false"
             userDNAttribute="distinguishedName"
             userNameAttribute="sAMAccountName"
             userContainer="OU=フォームベース認証するユーザを入れるOU,DC=xxx,DC=xxx"
             userObjectClass="person"
             userFilter="(&amp;(ObjectClass=person))"
             scope="Subtree"
             otherRequiredUserAttributes="sn,givenname,cn" />
      </providers>
    </membership>
    <roleManager enabled="true" >
      <providers>
        <add name="LDAPRole"
             type="Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
             server="ADサーバ名.xxx.xxx"
             port="389"
             useSSL="false"
             groupContainer="フォームベース認証するユーザを入れるOU,DC=xxx,DC=xxx"
             groupNameAttribute="cn"
             groupNameAlternateSearchAttribute="samAccountName"
             groupMemberAttribute="member"
             userNameAttribute="sAMAccountName"
             dnAttribute="distinguishedName"
             groupFilter="(&amp;(ObjectClass=group))"
             userFilter="(&amp;(ObjectClass=person))"
             scope="Subtree" />
      </providers>
    </roleManager>
  </system.web>

　- 対象の SharePoint Web アプリケーション（作成した名前）

 　・<membership defaultProvider="i">の<providers>セクションに以下を追記

        <add name="LDAPMember" type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" server="ADサーバ名.xxx.xxx" port="389" useSSL="false" userDNAttribute="distinguishedName" userNameAttribute="sAMAccountName" userContainer="OU=フォームベース認証するユーザを入れるOU,DC=xxx,DC=xxx" userObjectClass="person" userFilter="(&amp;(ObjectClass=person))" scope="Subtree" otherRequiredUserAttributes="sn,givenname,cn" />

　・<roleManager defaultProvider="c" enabled="true" cacheRolesInCookie="false">の<providers>セクションに以下を追記

        <add name="LDAPRole" type="Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" server="ADサーバ名.xxx.xxx" port="389" useSSL="false" groupContainer="OU=フォームベース認証するユーザを入れるOU,DC=xxx,DC=xxx" groupNameAttribute="cn" groupNameAlternateSearchAttribute="samAccountName" groupMemberAttribute="member" userNameAttribute="sAMAccountName" dnAttribute="distinguishedName" groupFilter="(&amp;(ObjectClass=group))" userFilter="(&amp;(ObjectClass=person))" scope="Subtree" />

２．Web アプリケーションの認証プロバイダの設定

　次は、Web アプリケーションに使用する認証プロバイダの設定を行います。
　[サーバの全体管理]から[Web アプリケーションの管理]を開き、対象の Web アプリケーションを選択し、[認証プロバイダー]を開きます。

認証プロバイダの領域では[既定]をクリックし、設定画面を開きます。

クレーム認証の種類のセクションで、[フォームベース認証（FBA）の有効化]にチェックを入れ、[ASP.NETメンバーシッププロバイダ名]に「LDAPMember（先ほど web.config に書いた名前）」、[ASP.NETロールマネージャ名]に「LDAPRole（先ほど web.config に書いた名前）」を設定し、保存します。

３．Web アプリケーションのユーザーポリシーの設定

　次は設定した認証プロバイダで認証されたユーザが Web アプリケーションへアクセスできるように設定します。
　先の手順と同様に[サーバの全体管理]から[Web アプリケーションの管理]を開き、対象の Web アプリケーションを選択し、[ユーザーポリシー]を開き、Web アプリケーションのポリシー画面で[ユーザーの追加]を開きます。

　対象の領域を聞かれるので[すべて]を選択し、[ユーザーの追加]画面の[ユーザーの選択]からユーザピッカーを開きます。

　[すべてのユーザー]から[すべてのユーザー（LDAPMember）]を追加し、元の画面に戻り、[権限の選択]で必要な権限を付与します。（画面は読み取り権限を与えています）

４．ユーザープロファイルとの紐づけ設定

　ここまでで認証とログインまでは出来るようになりましたが、SharePoint 上のユーザとの紐づけが出来ていません。つまり、認証とログインは出来ますが別途 User Profile Service 等で ID ストアから読み込んだユーザ情報と紐づけが出来ませんので、顔写真や姓・名などがうまく表示されない状態です。

　そこで、認証されたユーザと SharePoint 上のユーザプロファイルの紐づけ設定を行います。概念としては下図の通りです。

　今回作ったフォームベース認証プロバイダでは LDAP（AD）の sAMAccountName 属性を識別子として利用しているので、ユーザプロファイルの[クレームユーザーID]という属性が LDAP の sAMAccountName 属性の値と一致していれば同じユーザとみなす、という設定を行います。

　User Profile Service の詳しい設定については後日解説しますが、まず[サーバの全体管理]から[サービスアプリケーション]、[サービスアプリケーションの管理]、[User Profile Service Application]を開き、[ひと]セクションの[ユーザープロパティの管理]を開きます。
　この中の[クレームユーザーID]属性の編集を開きます。

　ここで認証プロバイダ LDAP の sAMAccountName をインポートするように設定し、保存します。

　この状態で[プロファイル同期の開始]で[完全同期]を行うと新しいマッピング状態を含めプロファイルが同期されます。 　これで設定は完了です。


５．動作確認

　では、先ほどのサイトへアクセスしてみます。設定が上手く行っていればサインイン方法の選択が出来るようになっています。

　ここでフォーム認証を選択すると認証フォームが表示されますので、認証DB（今回は Active Directory）上に作成したユーザの sAMAccountName とパスワードでログインします。

　ちなみに Active Directory 上に作成したユーザは以下の通りです。

　認証がうまくいくとサイトが使えるようになっており、プロファイルには Active Directory 上に設定したユーザの情報が反映されているはずです。下図は Active Directory 上に顔写真を入れておき、SharePoint へ同期した例です。

今回はここまでです。次回は SAML トークンベース認証を Windows Azure Access Control Service と設定し、Facebook や Google アカウントでログインする方法を解説します。

[FIM2010]各リリース毎のビルド番号

Forefront Identity Manager に限らず Microsoft 製品は割と頻繁にモジュール更新がされます。
しかし、実際は全部追いかけ続けるのは現実的ではないので、結局不具合が出てサポートに問い合わせて、言われて初めて当てる、という運用になっているのではないでしょうか？（特に作り込み要素が大きい製品なのでカスタムモジュールなどの動作確認を考えると出来るだけパッチは当てたくない類の製品だと思います）

ということをやっているといつの間にか新しい機能が追加されていたり、不具合が修正されていたり、機能が削除されていたり、、ということになってしまうので、各更新でどのような修正がされたかの情報がまとまっているとうれしいものです。

ということで、TechNet Wiki にそんなページがあるので FIM を運用している人はブックマークしておいた方が良いです。

FIM 2010 Build Overview
　http://social.technet.microsoft.com/wiki/contents/articles/2229.fim-2010-build-overview.aspx#Build_FourOhTwoFiveNineTwoRTM

ちなみに本日段階でのビルドは以下の通りです。

バージョン	ビルド番号	URL
RTM	4.0.2592.0
KB978864(Update1)	4.0.3531.2	http://support.microsoft.com/kb/978864/
KB2028634	4.0.3547.2	http://support.microsoft.com/kb/2028634/
KB2272389	4.0.3558.2	http://support.microsoft.com/kb/2272389
KB2417774	4.0.3561.2	http://support.microsoft.com/kb/2417774
KB2417774	4.0.3573.2	http://support.microsoft.com/kb/2417774
KB2502631	4.0.3576.2	http://support.microsoft.com/kb/2502631
KB2520954	4.0.3576.2	http://support.microsoft.com/kb/2520954/en-us
KB2635086(Update Rollup 2)	4.0.3606.2	http://support.microsoft.com/kb/2635086/en-us
KB2688078	4.0.3617.2	http://support.microsoft.com/kb/2688078/en-us
KB2737503	4.0.3627.2	http://support.microsoft.com/kb/2737503/en-us
KB2750673	4.0.3644.2	http://support.microsoft.com/kb/2750673/en-us
FIM 2010 R2	4.1.2773.0
KB2734159(for R2)	4.1.2515.0	http://support.microsoft.com/kb/2734159
KB2750671(for R2)	4.1.2548.0	http://support.microsoft.com/kb/2750671
KB2772429(Service Pack 1 for FIM 2010 R2)	4.1.3114.0	http://support.microsoft.com/kb/2772429
KB2814853	4.1.3419.0	http://support.microsoft.com/kb/2814853
KB2832389	4.1.3441.0	http://support.microsoft.com/kb/2832389/en-us

[FIM2010]ヴァーチャルラボで操作体験

昨年秋に開催した FIM2010 / AD FS2.0 のハンズオンですが、今年も再度開催をしたいとは考えてはいても、なかなか身体が空かず、、、という状態なので純正のハンズオンラボをご紹介します。待ちきれない方は是非こちらも触ってみてください。

Technet Virtual Labs - Forefront Identity Manager
　http://technet.microsoft.com/en-us/virtuallabs/bb499665

用意されているシナリオはそれなりにバリエーションが豊富で以下の通りです。

• Synchronizing Active Directory Users
• Inbound Synchronization Rules
• Backup, Restore, and Disaster Recovery, MA Run Scripts, and Final Configuration
• Joining Data from Another MA and Provisioning AD LDS
• The FIM Experience
• Importing and Synchronizing Data
• Managing Users in the FIM Portal
• Creating the FIM MA and Synchronizing
• Password Self-service and Configuring PCNS
• Managing Groups- Lab A
• Managing Groups- Lab B

ブラウザ上での操作になるのであまりパフォーマンスはよくありませんし、全編英語なのでそれなりのハードルはありますが一度使ってみるのも良いと思います。

[WAAD]アプリケーション統合でGraph APIを簡単に実行

先日のWindows Azure Active Directory（WAAD）の正式リリースでWAADと統合するアプリケーションを簡単に登録することが出来るようになりました。

実際にやっているのは、GoogleのAPIコンソールと同じく、OAuthのクライアントを登録することだけで、

• アプリケーション情報の登録（各種エンドポイント）
• クライアントIDとキー（Secret）の取得
• アプリケーションへ付与するWAADへのアクセス権限を設定

などが行えます。

ここでアプリケーションへ与えることが出来る権限ですが、

• シングルサインオン
• シングルサインオン、ディレクトリデータの読み取り
• シングルサインオン、ディレクトリデータの読み取りと書き込み

の3種類が用意されています。

シングルサインオンはSAMLプロトコルを使ってWAADとの認証連携をする機能、ディレクトリデータの読み取り、書き込みについてはGraph APIを使ってディレクトリデータを操作するための機能を指します。

と、いうことで今回は以前紹介したGraph APIを使って行うWAADのディレクトリデータの操作をアプリケーション統合の機能を使って、より簡単に実行する方法を紹介します。
（といっても簡単になるのはAccess Tokenの取得だけですが）

以前の記事では、Graph APIを利用するためのAccess Tokenを取得するのに、AAL（Windows Azure Authentication Library）を使ったコードを書いていましたが、この部分をアプリケーション統合機能で大幅に簡略化します。

手順はシンプルで、以下のステップだけです。

１．ディレクトリデータの読み取り権限のあるアプリケーションを作成する

　　⇒ClientID / Client Secretを取得する

２．WAADのOAuthのトークンエンドポイントへClient Credentials Grantフローでアクセスする

　　⇒Access Tokenを取得する

３．取得したAccess Tokenを使ってディレクトリデータを読み取る

※尚、OAuth2.0の各種フローと注意点についてはこの辺りを参照してください。

　RFCとなった「OAuth 2.0」――その要点は？

　http://www.atmarkit.co.jp/ait/articles/1209/10/news105.html

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

■ディレクトリデータの読み取り権限のあるアプリケーションを作成する

Windows Azureの管理ポータル（https://manage.windowsazure.com/）へログインし、Active Directoryの管理からディレクトリ⇒統合されたアプリケーションを選択します。

アプリの作成からアプリケーションを新規作成します。

[組織で開発中のアプリケーションを追加]を選択します。

アプリケーションに任意の名前を付けて、アクセス権を設定します。とりあえずユーザ情報の読み取りをしたいので、「シングルサインオン、ディレクトリデータの読み取り」を選択します。

URLやアプリIDなどは今回は特に使わないので適当に入れておきます。

取り敢えずアプリケーションが追加されるので、左上の[構成]メニューを開きます。

クライアントIDが生成されているのがわかります。クライアント Secretを生成したいので[キー]のところで時間の指定をします。

1年もしくは2年が選択できるので取り敢えず1年を選択します。保存するとキーが表示されます。

これで必要な情報（Client ID / Client Secret）がそろいました。


■WAADのOAuthのトークンエンドポイントへClient Credentials Grantフローでアクセスする

次は、取得したClient ID / Client Secret）を使ってAccess Tokenを取得します。

手順は簡単で、WAADのOAuthのトークンエンドポイントである
　　https://login.windows.net/＜テナントドメイン名＞/oauth2/token?api-version=1.0
に、

　- grant_type : client_credentials
　- resource : https://graph.windows.net
　- client_id : ＜先ほど取得した Client ID＞
　- client_secret : ＜先ほど取得した Client Secret＞
をPOSTするだけです。
※POSTするデータはURL Encodeしておく必要があります。

いつものAdvanced REST Clientを使ってアクセスしてみます。

すると、JSON形式でAccess Tokenが返ってきます。

これでAccess Tokenを取得できました。

コードを書かずに取得できるというのはとっても素晴らしいことです。

■取得したAccess Tokenを使ってディレクトリデータを読み取る

ここからはこれまでも何回か紹介した方法ですが、取得したAccess TokenをAuthorizationヘッダにセットしてディレクトリからユーザ一覧を取得します。

ユーザ情報が取得できました。

どうでしょうか？
Access Tokenの取得が格段に楽になっているのがわかると思います。
Office365のディレクトリ同期状況の確認などGraph APIの使い道は色々とありますので、一つ簡単なアプリケーションを作っておくと良いかも知れません。

Windows Azure の IaaS の正式リリースと FIM2010 R2 SP1 のサポート

永らくプレビューだった Windows Azure の IaaS がリリースされました。

Windows Azure チームの blog
　http://blogs.msdn.com/b/windowsazure/archive/2013/04/16/the-power-of-and.aspx

今回リリースされたのが IaaS ということで、各種 MS サーバ製品群を IaaS 上で動かすことが出来るか？という情報が KB として公開されています。

Microsoft server software support for Windows Azure Virtual Machines
　http://support.microsoft.com/?id=2721672

この KB を見ると、 Forefront Identity Manager 2010 R2 SP1 がサポートされています。
ただ、同時に以下の制限があるので、当面は大規模のプロダクション環境ではなく、小規模（たとえば Office 365 とのディレクトリ同期や部門で利用するクラウドサービスとの連携など）での利用やテスト環境として使われていくのかな？と考えています。

以下、動作に関する制限事項・考慮事項です。

• バックエンドとして、SQL Azure や別の（リモートの）SQL VMはダメなので、同一サーバ内で SQL Server も動作させる必要がある
• ドメインコントローラも IaaS 上に配置する必要がある。

A Guide to Claims-Based Identity and Access Control 2nd Editionが紙媒体でリリース

以前のポストで紹介した「A Guide to Claims-Based Identity and Access Control 2nd Edition」ですが、e-Book版のリリースから1年半が経過した今何故か紙媒体でリリースされたようです。（日本のAmazonでは売ってませんが、USのAmazonでは$50程度で売っています）

PDF版がMSDNで無償ダウンロード出来るのでどこまでニーズが有るのかわかりませんが、紙媒体が大好き！っていう方には良いかも知れません。2nd Editionでやたらとページ数が増えたのでPDF版を印刷して持ち歩くっていうのはほぼ不可能な量なので。。

（実は私、1st Editionの時はPDF版を印刷して読みました。その後著者のEugenio Paceさんにサイン入りの紙媒体をMS社内便で送ってもらいましたがｗ）

Amazon.comのURLはこちら。
http://amzn.to/10UZxhb

[WAAD]Windows Azure Active Directory が正式リリース

ようやく正式リリースされました。

Windows Azure チームの blog
　- Windows Azure Active Directory: Ready for Production with over 265 Billion Authentications & 2.9 Million Organizations Served!


細かいポイントはすでに色んな人が書いているので省略しますが、
・マイクロソフトアカウントで作成したWindows Azureテナントから利用が出来るようになった
・アプリケーション統合が管理ポータルから出来るようになった
というあたりが新規機能です。

ブチザッキ
　- Windows Azure AD/Backup Serviceほかいろいろ

Cloud Identity（Vittorio Bertocciのblog。MSDNから引っ越しました）
　- Windows Azure Active Directory Reaches General Availability
　- Walkthrough #1: Adding Sign-On to Your Web Application Using Windows Azure AD
　- Walkthrough #3: Developing Multi-Tenant Web Applications with Windows Azure AD

他にも Graph API で若干変更があったので、ここではその点を見ておきます。

最大のポイントは
・リクエストのパラメータに api-version を指定する必要がある様になった
・それに伴い、data contract version の指定が不要になった
という点です。

もちろん、今のところこれまでと同じエンドポイントも使えるのですが、その場合はこれまで通り data contract version を指定する必要があります。（しかも 0.5 / 0.8 のみ指定が可能）


ユーザ情報の取得を行う場合を例に新しいリクエスト方法を見てみます。

・エンドポイント：https://graph.windows.net/テナント名.onmicrosoft.com/users?api-version=2013-04-05
・メソッド：GET
・ヘッダ
　- Authorization/取得したJWT
　- Accept：application/json;odata=verbose;charset=utf-8
　　※簡易取得なら odata=verbose は不要

これまでは以下でした。
・エンドポイント：https://graph.windows.net/テナント名.onmicrosoft.com/users
・メソッド：GET
・ヘッダ
　- Authorization/取得したJWT
　- x-ms-dirapi-data-contract-version:0.5 or 0.8
　　※直近までは 0.9 も指定可能だったが、今は 0.5 / 0.8 しか受け付けない
　- Accept：application/json;odata=verbose;charset=utf-8
　　※簡易取得なら odata=verbose は不要

ちなみに古い形のリクエストで data contract version を付けないと HTTP 400 Bad Request が返ってきて、0.5 / 0.8 / 0.9 / 1.0 のどれかを指定するように言われるのですが、実際 0.9 や 1.0 を指定しても同じく Bad Request となってしまいます。

逆に新しい形のリクエスト（パラメータに api-version=2013-04-05 をつける）だと、data contract version をヘッダにつける必要はなくなり、Response ヘッダを見ると version 1.0 が使われていることがわかります。

後、実は大きな変更点なのですが、エンドポイントのリソース名（usersやgroups）が小文字しか受け付けなくなりました。
以前はリファレンスにも Users とか Groups と書いてありましたが、今は users や groups のようにすべて小文字にしないと 404 Not Found が返ってきます。

今後も以前の宣言通り OpenID Connect 対応など、IDMaaS としての機能が色々とリリースされるようなので、目が離せません。