[AAD/Office365]AAD Sync（次世代ディレクトリ同期）でクラウドのパスワードをオンプレミスへ

Office365を使う場合のシナリオは大きくは以下に分類されます。

パターン	認証	ID管理
クラウドのアイデンティティを使う	Azure AD	Azure AD
オンプレミス連携①	Windows Server ADなど	ディレクトリ同期など
オンプレミス連携②	Azure AD	ディレクトリ同期など

3番目のパターンにおいても最近のディレクトリ同期ツールではオンプレミスのActive Directory上のパスワード（のハッシュ）をAzure ADへ同期することが出来るようになっており、シングルサインオンではないもののユーザは同じパスワードでOffice365/Azure ADを使うことが出来るようになっていました。（SSO - Same Sign Onなんて言ったりします）

先日紹介した次期ディレクトリ同期ツールであるAAD Syncを使うと今度はクラウド（Azure AD）上のパスワードをオンプレミスのActive Directoryへ同期することが出来るようになります。

メリットは、Windows Server Active Directoryが標準では持っていないセルフサービス・パスワード・リセットがAzure ADでは使えるので、パスワードを忘れた人はAzure ADでパスワードをリセットすればオンプレミスのパスワードもリセットされる、という点でしょうか。

Technetに続々と情報が上がってきているので継続的にウォッチが必要そうです。
　http://social.technet.microsoft.com/wiki/contents/articles/tags/AADSync/default.aspx

[FIM2010]vNextが見えてきた。FIMからMIM（Microsoft Identity Manager） へ

昨年12月に次世代ロードマップが見えてきた、という話が出ていましたが遂に具体的な情報が見えてきました。

（また？）名前が変わります。今度は
「Microsoft Identity Manager」
です。Windows AzureがMicrosoft Azureへ変わったように、MicrosoftもWindowsだけじゃないよ、とういメッセージなんだろうな、と思います。

Server&Cloud Blogでの発表
　Forefront Identity Manager vNext roadmap (now Microsoft Identity Manager)


（関連ポスト）12月のポスト
　Important Changes to the Forefront Product Line
　[FIM2010]いよいよ次世代へのロードマップが見えてきた



詳細は来月のTechEd North Americaで発表されるようですが、今後の製品としてのフォーカスは以下の3点に向けられるようです。

• Hybrid scenarios that leverage cloud-based services delivered in Microsoft Azure, including Multi-Factor Authentication, Azure Active Directory application integration, analytics and reporting
• Support for the latest platforms and mobile devices with modern user interfaces
• Improved security with additional controls, analytics and auditing of administrative and privileged user identities and their access to Active Directory, Windows Server and applications

ここでもやはりMicrosoft Azure Active Directoryと絡めたオンプレミスとクラウドのハイブリッド・シナリオが強く意識されていますね。

詳細情報が楽しみです。

[AAD/Office365]エンタープライズ環境で使う上での課題への対応が続々と

これまでOffice365をエンタープライズで展開する際に課題になっていたのは大きくは以下の点だと思います。

①ドメイン名の問題
　AD FSを使ってFederationをする際、Office365で使うドメイン名とオンプレミスのActive Directoryが使っているドメイン名を合わせる必要がありました。そのため、.localドメインなど内部専用ドメインを使っている企業ではUPN（User Principal Name）を変更する、など結構大きな対応をする必要がありました。

②社内ドメインのフォレスト・ドメイン構成の問題
　現状のディレクトリ同期ツールではマルチフォレスト環境での同期はできませんでした。これまでは同期専用のドメインを新しく作って対応したり、と同じくこちらも大手術が必要になる場合がありました。


ここ最近の対応でそれらの問題に対して少しずつ解が提供されてきています。
まず①のドメイン名の問題です。


①Windows Server 2012 R2 update 1でのAlternative Login IDのサポート

　UPNを変更する代わりに別のログインIDを使ってAD FSへログインできるようになっています。
　詳しくはこちら
　　http://support.microsoft.com/kb/2927690/ja


次にフォレスト構成の問題です。

②Azure Active Directory Premium＋Forefront Identity ManagerもしくはAAD Syncの利用

　先日のポストでも書いたように、Azure Active Directory Premiumが先日の//Build 2014で発表され、Premiumの特典となっているFIM（Forefront Identity Manager）を使ってインテグレーションを行えばかなり柔軟に対応できます。
　加えてディレクトリ同期ツールの後継となるAAD Sync（Azure Active Directory Sync）のCTP版が公開されています。
　技術ドキュメントを含めこちらのサイトで公開されています。（ダウンロードするにはconnectサイトへの登録が必要）
　　http://www.aadsync.com/

　今回公開されたAAD Syncを使えばFIMをゼロから構築しなくても、あらかじめ設定された状態でマルチフォレスト環境であってもディレクトリ同期が出来るようになります。


他にもHybrid Identity Managementというキーワードで続々と情報が出てきそうなので継続的にウォッチが必要そうです。
　Hybrid Identity Management
　　http://www.microsoft.com/en-us/server-cloud/solutions/identity-management.aspx#fbid=qWbiPt7PEDF

[雑談]認証連携、ID連携そしてOAuth認証

アイデンティティ界隈って馴染みのない用語ばっかりが飛び交っている、というのもこの世界への参入障壁を高めている要因になっているんじゃないかな、と思っている今日この頃です。

と、言うことで崎村さんの「非技術者のためのOAuth認証（？）とOpenIDの違い入門」に絡めて考えてみました。
　参考：http://www.sakimura.org/2011/05/1087/


認証連携とかID連携っていうのは元々、Identity Federationの日本語訳だと思うのですが、まずはIdentityという用語を「認証」と訳してしまっている段階でアレな訳です。しかしかと言って明快に「これだ！」という和訳がないので仕方なく「ID連携」としてしまっているのが現状ですね。

実際の仕組みの意味的にいうと、RP（Relying Party）側の持っているアイデンティティ情報とIdP（Identity Provider）側の持っているアイデンティティ情報を「紐づける」というのがFederationの元々の意味合いなんですが、ここで混同されるのがSAMLで言えばいわゆるSAMLログオン（SAMLトークンを持っていることで認証する）という話や最近の類似した事例で言えばJWT（JSON Web Token）を使った簡易SSOっていうのがあったりして、ややこしくなるわけです。

そして、ここから拡大解釈されたのがOAuth認証（Access Tokenを持っていることで認証する）。。何だろうなぁ、、思っています

まとめるとこんな感じ。

	ID連携	簡易SSO	え？
例	SAML、OpenID Connectを使ったアイデンティティ情報（認証状態を含む）の紐づけ	SAML認証、JWTを使った簡易SSO	OAuth認証
何をもって認証するか	そもそも認証にクローズした話じゃない	デジタル署名などで検証可能なトークン（SAMLトークンやJWT）を持っている	（確かに持ち主に発行されたことを検証できない）トークンを持っている
用途	RPとIdPのアイデンティティ情報の紐づけ	シングルサインオン	シングルサインオン

この表を見ると簡易SSOって何よ？という話になると思いますが、シングルサインオンに求められる要件を考えると一目瞭然な訳ですが、代表的な例で言えばSLO（シングルログアウト）やセッション管理が出来ない、というところになると思います。
例えば、ちゃんとしたWAM（Web Access Management）ソリューションだとサーバ側でのセッションの強制終了や一つのサイト（RP）からログアウトすれば、すべての関連するRPからログアウトされるシングルログアウト何かが必須要件になると思いますが、SAML認証やJWTを使った簡易SSOでは単純にトークンを持っていること（もちろんトークンの発行先の検証や有効期限の検証はRP側でする前提）はあるものの、都度IdP側に該当トークンの有効性の確認までしない、というあたりがいわゆるシングルサインオンとの違いになってきます。

OAuth認証に至っては誰に発行したものなのか、についての検証すらしない（できない）というあたりが認証としての要件を満たしていないわけです。

現実世界のメタファに当てはめると、以下のような話になると思います。
・SAML認証、JWTでの簡易SSO：免許証など写真付き身分証明書を持ってきた
　⇒RP側（アプリ側）で持ってきた人の顔と証明書の顔写真が一致しているか検証可能
・OAuth認証：保険証を持ってきた
　⇒RP側では持ってきた人が主張すれば信じるしかない？


認証の話ばかりしましたが、連携の話をすると、RP側で持っているもしくは他のIdPから取得したアイデンティティ情報とFederation（連携：紐づけ）をして一つのアイデンティティとして認識をする、というのが本来のアイデンティティ連携です。この紐づけをする対象の属性の一つとして一番わかりやすいユースケースとして認証状態（どこで、いつ、どうやって認証された、という情報）があるのでFederationがシングルサインオンに使えるため、Federation＝シングルサインオンみたいな話になっているわけです。

そんなこんなで、良くこの界隈では話がされる内容ですが、
・ID＝Identityであって本質的には認証とは関係ない
・Federationも本質的には認証のための仕組みではない
・OAuthは認証には使っちゃダメ
ということです。

＜酔っぱらい＠新幹線にて＞