[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 としての機能が色々とリリースされるようなので、目が離せません。

[FIM2010]ECMA2.2と各種対応コネクタがベータリリース

そう言えば先日の FIM2010 R2 用の SP1 と共に 2.1 へとバージョンが上がった EMCA（Extensible Connectivity：拡張管理エージェント）ですが、早くも 2.2 のベータ版が Connect サイトに上がっています。

https://connect.microsoft.com/site433/Downloads/DownloadDetails.aspx?DownloadID=48615
※要登録

今回のバージョンの目玉はなんといっても「同期エンジンなしで実行できる様になったこと」です。この機能により、Visual Studio を使って単体で管理エージェントのテストやデバッグを実行できるようになりました。

他にも、
・コネクタを作成する際、機能のロードをユーザに情報を入れさせてから実行できるようになった。（例えば、SQL Server などから動的にスキーマを取得するようなコネクタを作ろうとした場合、これまでは SQL Server へ接続するユーザ情報を入力する前に機能をロードしようとして失敗していた）
・アンカー属性として LDAP の DN 形式をサポートした。
・delta import の際に object type の更新/削除できなくした。
という拡張がされています。


また、同時に EMCA2.2 に対応した以下のコネクタのベータ版もリリースされています。
・PowerShell MA
　もともと MCS(Microsoft Consulting Service)が個別で開発して使っていたコネクタのようですが、製品としてリリースされることになりました。
・SharePoint User Profile MA
　SharePoint のユーザプロファイルを管理するコネクタです。
・Generic LDAP MA
　汎用の LDAP コネクタです。XMA1.0 のサポート終了に伴い、コミュニティベースで公開されていた OpenLDAP XMA の代わりに使うことになりそうです。

最近特に FIM 関連の製品更新が多いので、なかなかついていけてません。。。

[Office365]AD FS2.0以外でSSOに挑戦

先日の MS 安納さんのポスト「【IDM】Windows Azure Active Directory と Office 365 と外部 IdP の関係（予想）」を見て、ちょうど Windows Azure Active Directory（WAAD）の中身を調査していたところだったので、色々と試してみました。

やろうとしたことは、WAAD の Access Control Service（ACS）を経由して Facebook や Google アカウントを使った Office365 へのシングルサインオンです。
結果、失敗するのですが、その過程で色々と仕組みが想像できたのでメモとして上げて起きます。

■まずは情報収集
現在、サードパーティ IdP での WAAD / Office365 へのフェデレーションの例としては、以下のような設定ドキュメントが公開されています。

・Ping Federate　 http://documentation.pingidentity.com/display/PFS/Set+up+Active+Directory+and+Directory+Synchronization#SetupActiveDirectoryandDirectorySynchronization-9000025
・Shibboleth
　http://technet.microsoft.com/ja-jp/library/jj205463.aspx

後は、AD FS2.0 でシングルサインオンを構成した WAAD / Office365 のドメイン設定がどうなっているのか、を直接調べるとことも参考になりそうです。

また、Offce365 のシングルサインオンに関するドキュメントを見ると Office365 側の前提事項なども見えてきます。
　https://portal.microsoftonline.com/IdentityFederation/IdentityFederation.aspx


調査の結果、WAAD / Office365 が外部 IdP とフェデレーションを行うには、以下が必要なことがわかります。

◆WAAD / Office365 側の状態
　- ディレクトリ同期が行われている状態であること
　　こんな記載があります。
　　シングル サインオン (ID フェデレーション) をセットアップすると、ユーザーは会社の資格情報でサインインして、Microsoft Office 365 for enterprises のサービスにアクセスできます。シングル サインオンのセットアップの一部として、ディレクトリ同期をセットアップする必要もあります。また、これらの機能をお使いの社内のディレクトリおよびクラウドのディレクトリに統合する必要があります。

　- シングルサインオンを有効にしたドメインを利用すること
　　まぁ当たり前ですが、ログイン画面（https://login.microsoftonline.com/login.srf）でログイン ID のドメインパート（@以下）を判別して、ログイン先の IdP を判別する以上、WAAD / Office365 がシングルサインオンドメインとして認識しているドメインが必要です。

　　ドメインの設定は Set-MsolDomainAuthentication コマンドレットを使うのですが、必要なパラメータは以下の通りです。
　　- DomainName : ドメイン名
　　- FederationBrandName : ブランド名（表示名）
　　- ActiveLogOnUri : Active Logon をする場合のエンドポイント
　　- IssuerUri : IdP の EntityID
　　- PassiveLogOnUri : Passive Logon をする場合のエンドポイント
　　- LogOffUri : ログオフする際のエンドポイント
　　- MetadataExchangeUri : Metadata Exchange のエンドポイント
　　- PreferredAuthenticationProtocol : 利用するフェデレーション・プロトコル
　　- SigningCertificate : 署名に利用する証明書

　　ちなみに AD FS2.0 と連携している WAAD / Office365 のドメインの情報を Get-MsolDomainFederationSettings コマンドレットで取得すると以下のような状態になっています。

パラメータ	設定値
DomainName	ドメイン名（コマンドレットの引数として指定）
FederationBrandName	FQDN
ActiveLogOnUri	https://FQDN/adfs/services/trust/2005/usernamemixed
IssuerUri	http://FQDN/adfs/services/trust
PassiveLogOnUri	https://FQDN/adfs/ls/
LogOffUri	https://FQDN/adfs/ls/
MetadataExchangeUri	https://FQDN/adfs/services/trust/mex
PreferredAuthenticationProtocol	WSFed（コマンドレットでは出ない）
SigningCertificate	証明書の値

◆外部 IdP の設定
　当然、外部 IdP 側には RP として WAAD / Office365 を設定する必要があリます。
　WAAD / Office365 の Federation Metadata が
　　https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml
　で公開されているので、中身を見てみます。
　必要なのは、IdP から見ると Audience に該当する EntityID 部分とトークンを POST するアサーション・コンシューマ・サービスのエンドポイントアドレスです。
　Federation Metadata を見ていくと、
　- entityID="urn:federation:MicrosoftOnline"
　- AssertionConsumerService ～中略～ Location="https://login.microsoftonline.com/login.srf"
　とあります。

　あとは、使用するプロトコルですが、Set-MsolDomainAuthentication コマンドレットなどフェデレーションドメインの設定用ツールのオプションである PreferredAuthenticationProtocol がとりうる値を見ると、WSFed / SAMLP とあるので、WS-Federation もしくは SAML-P が可能なことがわかります。
　今回は ACS を使ったので、自動的に WSFed を選ぶことになりますが、その場合に SAML トークンのバージョンが気になります。FireFox の SAML Tracer などを使って AD FS2.0 と WS-Federation で連携している WAAD / Office365 との間を飛んでいる SAML トークンを見ると、
　　saml:Assertion+MajorVersion="1"+MinorVersion="1"+AssertionID=xxx
　という記述が見えるので、 SAML トークンは 1.1 を使うことがわかります。

◆アサーション（クレーム）
　- AD FS2.0 の要求規則を見ると、以下のアサーション（クレーム）が発行されることが必要です。

Attribute	Type	Value
nameidentifier	http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier	AD上のオブジェクトのGUIDの値をbase64エンコードしたもの
UPN	http://schemas.xmlsoap.org/claims/UPN	AD上のオブジェクトのUserPrincipalName（xx@xx.com）
ImmutableID	http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID	AD上のオブジェクトのGUIDの値をbase64エンコードしたもの

　　ちなみに、AD FS2.0 が実際にどのようなアサーションを出しているのかを確認する場合は、ClaimGrabber（http://www.theidentityguy.com/articles/2011/6/5/introducing-claimgrabber.html）を使うと便利です。

　　当然、このアサーションの中のそれぞれの値が WAAD / Office365 上に同期されたユーザの属性と一致している必要があります。（特に NameIdentityfier として使われる ImmutableID の値が重要）
　　ユーザの属性を調べるには Get-MsolUser コマンドレットを使います。
　　こんな感じで、ImmutableID の値を取得します。
　　＞ Get-MsolUser -UserPrincipalName xxx@xxx.com | fl ImmutableID
　　すると、
　　ImmutableId : VNzO5OVz+Emv66IULItTCg==
　　という形で値が取得できます。



まとめると、以下が外部 IdP と WAAD / Office365 のフェデレーションの条件になりそうです。

対象	条件
WAAD / Office365	ディレクトリ同期	構成済みであること
	ドメイン	シングルサインオンドメインが構成されていること
外部 IdP	RP の 識別子（EntityID）	urn:federation:MicrosoftOnline
	RP の エンドポイント	https://login.microsoftonline.com/login.srf
	プロトコル	WS-Federation
	SAML トークン形式	SAML 1.1
アサーション	NameIdentifier	ADのGUIDをBase64エンコードした値（Get-MsolUserで取得した値と一致していること）
	ImmutableID	同上
	UPN	ADのUserPrincipalNameの値

■実際にやってみる
では、早速 ACS を使って上記を構成してみます。

◆WAAD / Office365
　ディレクトリ同期は普通に DirSync を使って構成します。
　具体的なやり方は、手前味噌ですが、
　　@IT / Office 365とのアイデンティティ基盤連携を実現する（前）
　　http://www.atmarkit.co.jp/ait/articles/1211/14/news069.html
　を参考にしてください。

　ドメインの設定ですが、ACS の Federation Metadata から取得した値を設定します。
　ACS の Federation Metadata は
　　https://テナント名.accesscontrol.windows.net/FederationMetadata/2007-06/FederationMetadata.xml
　なので、必要な値はここから取得します。
　といっても使うのは IssuerUri と PassiveLogOnUri と MetadataExchangeUri だけです。
　- IssuerUri : https://テナント名.accesscontrol.windows.net
　- PassiveLogOnUri : https://テナント名.accesscontrol.windows.net/v2/wsfederation
　- MetadataExchangeUri : https://waadnew1.accesscontrol.windows.net/v2/wstrust/mex

　これらの値を使って WAAD / Office365 上にドメインを構成します。
　まずは、ドメイン自体の作成です。
　＞ Connect-MsolService
　で WAAD / Office365 へ接続し、
　＞ New-MsolDomain -Name 作成するドメイン名 -Authentication Federated
　と打ってフェデレーションドメインを作成します。

　次に、ドメイン所有権の確認のための CNAME レコードの出力と作成です。
　＞　Get-MsolDomainVerificationDns -DomainName 作成したドメイン名
　ここで出てくる Label の値を DNS 上に登録します。

　登録が完了したら、確認と同時に IdP の設定もしてしまいます。

　＞ $domainName = "ドメイン名"
　＞ $brandName = "ラベル名"
　＞ $issuerUri = "https://テナント名.accesscontrol.windows.net"
　＞ $passiveLogOnUri = "https://テナント名.accesscontrol.windows.net/v2/wsfederation"
　＞ $logOffUri = "https://テナント名.accesscontrol.windows.net/v2/wsfederation"
　＞ $activeLogOnUri = "https://テナント名.accesscontrol.windows.net/v2/wsfederation"
　＞ $metadataExchangeUri = "https://テナント名.accesscontrol.windows.net/v2/wstrust/mex"
　＞ $signingCertificate = "証明書の値"

　として引数を設定し、Confirm-MsolDomain コマンドレットを実行します。
　＞ Confirm-MsolDomain -DomainName $domainName -FederationBrandName $brandName -ActiveLogOnUri $activeLogOnUri -IssuerUri $issuerUri -PassiveLogOnUri $passiveLogOnUri -LogOffUri $logOffUri -MetadataExchangeUri $metadataExchangeUri -PreferredAuthenticationProtocol WSFed -SigningCertificate $signingCertificate


◆ACS の設定
　次は ACS の設定です。
　ACS の IdP の設定として Facebook や Google などを設定するのですが、ここでは詳細は省略します。Facebook の場合、Facebook 上にアプリを構成して Consumer Key と Consumer Secret を取得するのと、Callback URL に ACS を設定するだけです。

　ここでは RP 設定（証明書利用者アプリケーション）とクレーム・ルール（規則グループ）の設定を行います。
　まずは RP 設定は以下の通りです。
　- 領域 : urn:federation:MicrosoftOnline
　- 戻り先 URL : https://login.microsoftonline.com/login.srf
　- トークン形式 : SAML 1.1

　次にクレーム・ルールですが、どうやって Facebook などから AD の GUID を Base64 エンコードした NameIdentifier / ImmutableID を取得しようか、、という話になります。
　やり方としては実は ImmutableID は必ずしも AD の GUID を Base64 エンコードした値そのものでなくても良い、という点を利用します。ユーザを WAAD / Office365 に作っているのはディレクトリ同期ツール（つまり FIM2010）なので、ImmutableID（ディレクトリ同期ツール上では SourceAnchor）に Facebook から取得できる他の値に設定してあげればよいわけです。
　ACS が Facebook から取得するクレームとしては Facebook 上のユーザID（数字の羅列）があるので、それを ImmutableID として設定してしまいます。
　簡単なアプリケーションを作って ACS が Facebook から取得する nameidentifier の値を取得し、それを AD 上のどこか適当な属性の値に設定し、ディレクトリ同期ツールの属性マッピングの設定を変えてしまいましょう。

　と、正攻法？は上記なのですが、面倒なので、逆のアプローチもあります。
　AD と同期したユーザの ImmutableID の値を ACS が nameidentifier や ImmutableID として出力できればよいわけなので、ACS の出力要求の値に直接取得した ImmutableID の値を入れてしまいます。当然一人しか使えなくなりますが、実験なので良しとします。

ここまでで一通りの設定は終わりです。さっそく実験します。

■いざ、試す
結果、失敗します。

ここまでは順調。

そして失敗。。。


■原因を考えてみる。。
　正常に使える AD FS2.0 でのログオンの場合と、失敗する Facebook のパターンを比較してみます。
　Firefox の SAML Tracer を使って https://login.microsoftonline.com/login.srf に POST されるアサーションの中身を比較してみます。
　saml:AttributeStatement の中身はほぼ同じです。AD FS2.0 側は NameIdentifierに Format プロパティで urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified が設定されていますが、AD FS2.0 のクレーム・ルールのオプションを付ける部分を削除してもちゃんとログオンはできたのでここは原因ではなさそうです。

　しかし、そのままアサーションを見ていくと、、ありました、圧倒的な違いが。
AD FS2.0 の出力したアサーションには AuthenticationStatement が存在しますが、ACS の出力したアサーションには AuthenticationStatement がありません。
　確かに ACS 自体は認証をしている訳ではないので AuthenticationStatement が出力されるわけがありません。ちなみに ACS の IdP を Google にしても結果は同じなので、ACS の先の IdP がどうやって認証したのか？という情報は ACS からの出力クレームには含まれません。

　ということで、おそらく原因はこれです。
　尚、私はここであきらめたのですが、どなたかその先を深堀して出来れば解決してみて頂きたいなぁ、、と。


■実験を通しての感想
　ACS は非常に便利なのですが、クレーム・ルールの編集でできることが非常に少ないです。せめて AD FS2.0 の要求規則の編集程度のカスタマイズが出来れば色々と可能性が広がると思います。

[IdM用語]NASCAR問題

アイデンティティ界隈では普通に使われている言葉なのに Google 先生に聞いてみても答えが出てこない言葉って結構あったりします。
その一つが、「NASCAR 問題」です。

日本語でそのまま検索すると Wikipedia の OpenID のページに以下のように記述があります。

Account ChooserOpenID Authentication 2.0, OpenID Connect のみではなく、SAMLなどでも問題になる ユーザーインターフェースの問題 (NASCAR問題、WAIF問題）を解決すべく検討されている 仕様。

どうやらユーザーインターフェースの問題らしい、というところまではわかりますが、具体的にどういう問題なのか、NASCARって何なのか、についてはよくわからないままです。



というわけで簡単に解説です。（もっとうまく解説できる、もしくは違うよ、という方はご連絡・ツッコミください！）

簡単に言ってしまうと、
OpenID や SAML などで外部 IdP を使ってサービスへログオンするとき、IdP が増えてくるとユーザが自分がログオンに使う IdP を探し出すのが難しくなって利便性が下がってしまう
という問題です。
ログオンメニューに Facebook のアイコンや Twitter のアイコン、Yahoo! や Mixi や、、、という様にずらりと並んでいるのを見たことはないでしょうか？

例えば OpenID Foundation のページへログオンするときは以下の様に自分が使う OP（OpenID Provider）を選択することになります。

で、Account Chooser を使うと一回ログオンした IdP の情報を覚えておいてくれるので、毎回使ってもいない IdP が沢山並んでいる中から自分が使う IdP を選んでログオン、という手間が省けますよ、という流れです。
ちなみに Account Chooser 自体に関する情報は OpenID Foundation Japan の Evangelist である @nov 氏、 @ritou 氏が解説しているので、ここを参照してください。

- @IT の記事 by @nov 氏
　セキュアで使いやすい認証UX標準化を目指すAccount Chooserプロジェクト
　http://www.atmarkit.co.jp/ait/articles/1301/28/news010.html

- r-weblife by @ritou 氏
　GoogleでわかるAccount Chooser
　http://d.hatena.ne.jp/ritou/20111119/1321688092


で、NASCARって何なのか？だけが残ってしまいました。
NASCAR（ナスカー）とは National Association for Stock Car Auto Racing / 全米自動車競争協会のことです。

こんな車が走ってるレースです。

これとアイデンティティとの関係ですが、車を良く見ると各スポンサーのロゴステッカーが所狭しと並んでいるのが見えると思います。これって先ほどの IdP のロゴが並んでいるのと似てますよね？ということで、NASCAR みたいだから NASCAR 問題ということです。

他にも色々とマニアック用語がありそうなので、時々解説していこうと思います。