ACSでWindowsLiveIDを使う場合に割と普通にはまるポイント

若干わかる人にしかわからないタイトルになっていますが、内容的にはFAQになりそうなポイントなのでいつも通り解説していきます。

環境を作る上での詳細な手順は以前紹介した内容や割と普通さんの日記を参照してください。

■問題が発生する状況

・AppFabric Access Control Service(ACS)を使って外部認証するアプリケーション(RP)を作りたい。※ACSはLab版

・認証(IdP)はWindows LiveIDを使いたい。

■問題

・Windows LiveIDで認証された後、クレームが取得出来ない（様に見える）

・Googleで認証するとうまくクレームの取得ができる

単純なWIFを使ったアプリケーションでPage_Loadで画面上にPage.User.Identity.Nameの値を表示するもの。

Googleで認証されると取得できる。

■原因は何か？

先に結論を言ってしまいますが、アプリケーションが使いたいクレームをWindows LiveIDが提供していないことが原因です。

通常クレームを使うアプリケーションは取得したクレームから利用者を特定するためにWIFによってプロパティに設定されるPage.User.Identity.Name変数を利用します。

しかし、この変数はClaimType=http://schemaes.xmlsoap.org/ws/2005/05/identity/claims/nameという型でクレームが発行されていないとセットされないので、Identity Providerがname属性のクレームを発行していないと変数には何も入りません。

ACSのClaim Ruleを見てみるとIdPにWindows LiveIDを選択するとInput Claim Typeにはnameidentifierの1種類しか選択できないことがわかります。

実際に発行されたトークンの中身を見てみてもnameidentifier以外のクレームは発行されていません。

トークンの中身を見るにはいくつか方法があるのですが、ここではCodePlexに公開されているSecurityTokenVisualizerを使います。（詳しい使い方は後日紹介します）

Googleで認証するとうまくいくのはGoogleがname属性を提供しているからです。

■ではどうしたら良いのか？

そもそも何故Windows LiveIDではnameidentifier以外の属性を発行していないのでしょうか？また、nameidentifier属性に入っている値は何を意味するのでしょうか？nameidentiferに入っている値から他の属性の値を取得することはできないのでしょうか？

答えはMSDNフォーラムにありました。

http://social.msdn.microsoft.com/Forums/en/windowsazuredevelopment/thread/01024798-99c3-4dd6-ac46-413bb35b3240

-----------------------------

For LiveId, the NameIdentifier is an unreversable hash of the user's Live PUID and is therefore not usable to get more information. This behavior is due to Windows Live privacy requirements. Currently one possible workaround is to manually add mapping rules to map the hash code to a specific username on ACS labs portal.

-----------------------------

要するに、

・nameidentifier属性にはWindows Live IDのPUID※のハッシュ値が入る

　※account.live.comに表示される固有ID

・この値から他の属性の取得はできない

・これはWindows Liveのプライバシー上の理由からである

・ワークアラウンドとしては各nameidentifier属性に入るハッシュ値とユーザ名を手動でマッピングするしかない

ということです。

インターネット上のアイデンティティという話をするとどうしても避けて通れないプライバシーの問題に行き当たるようです。SAML2.0の仮名と同じ考え方ですが、特定のRPでしか使えない識別子を割り当てることによりそのユーザが他にどのようなRPを使っているかの特定、また他のRPへは提供されている属性を識別子をキーに収集して本人の同意がない形でアイデンティティを見える化されてしまうことを防ぐための仕様です。（これもまた別の機会に解説します）

結果的にフォーラムにもあるワークアラウンドを用いる形になりますが、何もACS側のマッピングにユーザの属性を個別にマッピングする必要はなく、「認証」と「ユーザ属性の管理」を分離して考えて、

・認証：Windows Live ID

・ユーザ属性の管理：アプリケーション

で実施するのが現実的だと思います。

具体的にはWindows Live IDで認証された後、取得できるPUID（のハッシュ値）をアプリケーション側のユーザテーブルと紐付けて、初めてのPUIDならユーザ情報を登録し、すでに存在するPUIDなら登録済みのユーザ情報をベースにアプリケーションを開始する、という流れになります。（Googleなど他の属性も取得できるIdPを使う場合はある程度の情報はユーザテーブルに初期値として登録してあげればよい）

このあたりはそのうちサンプルアプリケーションを作って公開でもしようかと思います。

【祝】日本語化！クレーム ベース ID およびアクセス コントロールのガイド

以前のポストで紹介した「A Guide to Claims-Based Identity and Access Control」が日本語化されました。

以前のポスト

・クレイムベースのアイデンティティ＆アクセスコントール本が届きました

・早わかり！クレイムベースのアイデンティティ＆アクセス管理

英語版で読んでもかなり理解しやすく書いてあったので、日本語になったことでクレームベースアイデンティティの分野のハードルが下がったかな？と思いますので、是非読んでみてください。

後は、VittrioのWIF本が日本語化されれば完璧ですがあまりにも読者層が薄いと思われるので中々難しいんでしょうね。

カンターラ・イニシアティブ技術セミナー2010に参加してきました（12/19更新）

【12/19更新：資料が公開されました】

12/14にカンターラ・イニシアティブ技術セミナー2010が新宿であったので参加してきました。

今回は

・SAML標準技術を活用した学術認証連携基盤の構築

　国立情報学研究所 学術ネットワーク研究開発センター 教授 中村 素典さん

・バックオフィス連携実験におけるID連携技術の適用

　株式会社NTTデータ リージョナルビジネス事業本部 永田 敏之さん

の2本立てでした。

話の流れはいずれ資料が公開されると思いますし、それまでは@hirokiさんがtogetterしてくれたのでそちらを見ていただければある程度流れはわかると思いますが、ざっくりおさらいをしておきます。

メインテーマに入る前にJapan Workgroupの坂本さんから最近のKantara Initiativeの活動を紹介してくださいました。これまで各WGの活動と他のWGとの関連性をまとめた資料は見たことがなかったのでとても貴重な話でした。

前回のシンポジウムのメインテーマだったことからもわかりますが、最近Kantara Initiativeが一番注力しているのがIAF(Identity Assurance Framework)で、IAF WG以外のいくつかのWGの活動もIAFに絡んでいる、という話もありました。

資料はこちら：http://kantarainitiative.org/confluence/download/attachments/45057108/KantaraJapanWGseminar20101214.pdf

次にメインの1本目、NIIの中村教授のShibbolethの話ですが、これはUSTで見ていた人にはわからないと思いますが、「学認ベスト(笑)」をまず最初に披露していました。（どこに売っているんだろう？？）※学認（GakuNin）＝学術認証ネットワーク

普段は基本的にエンタープライズを相手にお仕事をしているのでShibbolethは全くの門外漢なのですが、非常に基本的なところからShibbolethを解説していただき非常に役に立ちました。

基本的な考え方はSAML対応のWebSSOとDS（Discovery Service）がセットになった仕組みなので、他のWeb SSOとあんまり変わりませんが特徴としては以下の様な所であると感じました。

・スキーマ（eduPersonなど）が標準化されておりSPでの認可が共通化されている

　この辺りは共通基盤の強みです。

・DSとセットになっている

　複数IdP（各大学）と連携することを前提に作られているのでIdPを選択させる仕組みが必要になります。

・Federation Metadataを学認が取りまとめている

　通常はIdPとSPの間の信頼とFederation情報のやり取りは個別にやりますが、ここも共通基盤の強みですが、学術認証ネットワークに参加しているIdP（大学）と対応するSP（アプリケーション）の情報を一元管理しています。

・UPKIとの連携

　基本モデルはSPとIdPの間の信頼関係にある点は当然他のSAMLの仕組みと何ら変わらないので証明書のやり取りが発生しますが、事前に学認に参加する大学を審査しておくことにより使用するサーバ証明書の発行を簡素化する、という仕組みも構築されているそうです。

次にバックオフィス連携の実証実験の話ですが、これは電子行政（住民票の電子申請とか）を推進するために裏側（バックオフィス）で各自治体などとセキュアに情報をやり取りするための取り組みに関する話でした。

今後このバックオフィス連携の仕組みが自治体や各省庁の間の情報連携を行うための情報ハブ・プラットフォームとなるということでした。

現段階では実証実験ですが、SAML2.0 / ID-WSF2.0を採用しフェデレーションやプライバシー情報の連携を行っており、かつそれらの要素技術を何故選択したのか？などについても解説があったので非常に参考になりました。

また、行政関連ということで特徴的だったのが例えば障害等級の情報など非常にセンシティブな情報を扱うことが前提となる仕組みなのでID-WSFなど本人の同意の元で最低限の情報を連携する仕組みが必要になってくるということでした。他にも自治体職員が本人の代わりに過去に本人が在住していた自治体から情報を取得する時にいかにプライバシーを保護するのか？というテーマでのユースケースが紹介されたりと興味深い点が数多くありました。

とりあえずメインセッションの資料の公開を期待して待っておきましょう。

すみません、字ばっかりで。

[ADFS2.0] SAML 2.0ベースのWebSSOシステムとの連携

マイクロソフト フランスのPhilippe BeraudさんとUPMC（French University Pierre and Marie Curie）のJean-Marie Thiaさんの共著のホワイトペーパーが公開されています。

Using AD FS 2.0 for interoperable SAML 2.0-based federated Web Single Sign-On
[直リンクです]※元のダウンロードページがわからなかったので。。。
http://download.microsoft.com/documents/France/Interop/2010/Using_ADFS2_0_For_Interoperable_SAML_2_0-Based_Federated_SSO.docx

これまで個別のWebSSO製品とのフェデレーションのSTEP-BY-STEPガイドはリリースされてきましたが、根本的にAD FS2.0ろSAMLの相互運用性について書いたドキュメントはGenevaの時代を含めなかった様に記憶しています。

[参考：これまでリリースされた各種WebSSO製品とのフェデレーションガイド]
・CA Federation Manager
　http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=fef76ca4-5677-4356-afb1-196d8f92dc79
・Oracle Identity Federation
　http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=46bd1cc0-cbe1-4426-875d-428b25b65f1a
・Shibboleth 2 / InCommon Federation　（製品じゃないけど）
　http://technet.microsoft.com/en-us/library/gg317734(WS.10).aspx

　※他にもGenevaの時代にNovell Access ManagerやSun OpenSSOとの相互運用性のホワイトペーパーはありました。
　　http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=9eb1f3c7-84da-40eb-b9aa-44724c98e026




そんな状況を踏まえてこのホワイトペーパーでは以下を目的にしています。
-------------------------------------------------------------------------

For that purposes, beyond a short depiction of AD FS 2.0 to introduce key
concepts for the rest of the paper, it gives an understanding of:
・ What the SAML 2.0 standard is all about,
・ What its support makes possible,
・ The common "gotchas" that may be encountered along with AD FS 2.0.
So that federation projects involving AD FS 2.0 in this context can be more easily
completed, and consequently enabling customers to realize the full
interoperability potential of AD FS 2.0.

--------------------------------------------------------------------------

要は、SAML 2.0とは何であるか？、何が出来るのか？、AD FS 2.0を使うときに引っかかるポイントはなんなのか？を理解するためのもの、ということです。
これからAD FS2.0やSAMLに取り組む人にはかなり役に立ちそうです。


以下に目次を紹介しておきます。

1 INTRODUCTION
1.1 OBJECTIVES OF THIS PAPER
1.2 ORGANIZATION OF THIS PAPER
1.3 ABOUT THE AUDIENCE
1.4 TERMINOLOGY USED IN THIS PAPER
1.5 ABOUT THE LIVE DEMO AT THE MTC PARIS
2 AN UNDERSTANDING OF THE SAML 2.0 STANDARD
2.1 A SUITE OF SPECIFICATIONS
2.2 SAML 2.0 ASSERTIONS
2.3 SAML 2.0 PROTOCOLS
2.4 SAML 2.0 BINDINGS
2.5 SAML 2.0 PROFILES
2.6 SAML 2.0 OPERATIONAL MODES
3 A BRIEF OVERVIEW OF ACTIVE DIRECTORY FEDERATION SERVICES (AD FS) 2.0
3.1 A PASSIVE/ACTIVE SECURITY TOKEN SERVICE (STS)
3.2 FEDERATION IN HETEROGENEOUS ENVIRONMENTS
3.3 AD FS 2.0 AND THE BUSINESS READY SECURITY
4 THE ELEVEN INTEROPERABILITY "GOTCHAS" YOU SHOULD BE AWARE OF
4.1 ENCRYPTION
4.2 SIGNING
4.3 CRL CHECKING
4.4 METADATA HANDLING
4.5 NAME ID FORMATS
4.6 PERSISTENT & TRANSIENT NAME IDS
4.7 SHARING ATTRIBUTES WITH SAML 2.0 SPS
4.8 HTTP ARTIFACT BINDING
4.9 PRE-FORMATTED HYPERLINKS
4.10 SSO FROM SAML 2.0 IDPS TO WIF RELYING PARTY APPLICATIONS
4.11 IDP DISCOVERY
APPENDIX A. AD FS 2.0 CUSTOMIZED FILES

「AD FS 2.0 デザインガイド」の日本語版

なかなか日本語リソースが少ないこの領域ですがだんだんドキュメントの翻訳が進んできているようです。

今日も以下のURLで「AD FS 2.0 デザインガイド」の日本語版が公開されています。

http://technet.microsoft.com/ja-jp/library/gg308546.aspx

















コンテンツは以下の構成となっています。
・AD FS 2.0 を展開する前に重要な概念について理解する
・AD FS 2.0 の展開目的を特定する
・展開目的を AD FS 2.0 設計にマップする
・展開を計画する
・フェデレーション サーバー の配置を計画する
・フェデレーション サーバー プロキシの配置を計画する
・付録 A: AD FS 2.0 の要件を確認する

私もAD FS 2.0（当時はGenevaでしたが）を触り始めたころは英語版のマニュアルと格闘していたのですが、その後このデザインガイドの英語版やEuginio Paceさんの「A Guide to Claim-Based Identity and Access Control」やVittorio Bertocciさんの「Understanding Windows CardSpace」を参考にして小難しい概念を理解しようとしていた思い出があります。





































なかなか特殊な分野なのか日本語での書籍は商業的にも難しいのかも知れませんが、このように日本語のオンラインドキュメントが出てきたことで初めの一歩のハードルは下がってきたのかも知れません。
（一部製品のメニューの日本語名とは異なる用語が使われてしまっているので混乱はあるかも知れませんが・・・。元々のメニューの日本語がわかりにくすぎる、という説もｗ）