2014年4月18日金曜日

[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

2014年4月14日月曜日

[雑談]認証連携、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を使った簡易SSOOAuth認証
何をもって認証するかそもそも認証にクローズした話じゃないデジタル署名などで検証可能なトークン(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は認証には使っちゃダメ
ということです。

<酔っぱらい@新幹線にて>

2014年3月30日日曜日

[AAD+FIM2010]Azure Active Directory Premiumの正式リリースとプロビジョニング界のエコシステムの崩壊?

Windows Azure Active Directory(WAAD)あらためMicrosoft Azure Active Directory(MAAD?最近はAADで通じるっぽい)のPremiumが4月に正式リリース(GA)を迎える、ということがActive Directory Teamのblogでアナウンスされました。

Cloud based Identity and Access Management for every user on every device
 http://blogs.technet.com/b/ad/archive/2014/03/25/identity-and-access-management-for-every-user-in-every-organization-using-any-service-on-any-device.aspx


来週からのBuild(4/2-4/4)で発表されるんですかね。

blogの内容を見ると、AAD PremiumにはForefront Identity Manager(FIM)のサーバライセンスとCALが含まれるそうなので、マルチフォレストシナリオでのディレクトリ同期やオンプレミスのActive Directory以外をデータソースとしたID管理などの複雑な構成がとれるようになります。



これはエンタープライズID管理(特にプロビジョニング)市場にとって非常に大きなインパクトを持つ可能性があると考えています。エンタープライズシナリオでOffice365とか使おうと思ったら今後はAAD Premium+FIMっていうのがコスト的にも非常に優位なソリューションになる可能性がありますので、これまでAAD/Office365のディレクトリ同期ツールで足りない部分はサードパーティを、というエコシステムが成り立ってきましたが、今後すこしバランスが崩れる可能性があるのでは?と思います。


最後に、改めてですが今回正式リリースとなるAAD Premiumの機能は以下の通りです。
他にもPreview中の機能が複数あり、今後も強化されていくようです。

全体的な特徴

  • 99.9%のSLA
  • ディレクトリ内のオブジェクト数に制限なし

機能
  • アプリケーションアクセス管理
    • Google AppsやsalesforceなどへのSSO/プロビジョニングを提供、アプリケーションポータル(アクセスパネル)からアプリケーションの利用
  • セルフサービス・パスワードリセット
    • ユーザ自身によるパスワードリセット
  • セルフサービス・グループ管理
    • ユーザ自身によるグループの作成やグループへの参加登録
  • 多要素認証
    • 追加のソフトウェアやハードウェアなしでの多要素認証の提供
  • ブランドのカスタマイズ
    • ログイン画面やアクセスパネルなどの画面カスタマイズ
  • レポーティング、警告と分析
    • アクセス元ネットワークの解析や利用状況のレポート


2014年3月15日土曜日

[FIM2010]PowerShellコネクタの正式リリース

Forefront Identity Manager 2010 R2 (FIM2010 R2)用のコネクタが更新されています。

◆PowerShell コネクタの正式リリース
 これまで PowerShell コネクタと言えばデンマークの FIM MVP の Soren Granfeldt さんが公開していたものでしたが、マイクロソフトからも正式にリリースされました。どうやらこれまで MCS(Microsoft Consulting Service)が使っていたものを製品に組み込んだ、ということらしいです(うろ覚え)

 用途としては、ホームディレクトリをファイルサーバに作ったり、Office365 へのプロビジョニング後にライセンスをアサインしたり、と小回りを聞かせたいときに使うのがメインになりそうです。

 こちらからダウンロードできます。

◆Generic SQL コネクタの RC 版(リリース候補版)
 ODBC ドライバがある DBMS へ接続できるコネクタです。これまではビルトインの SQL コネクタと Oracle コネクタしか用意されていませんでしたが、これでもう少し柔軟なシステム管理ができるようになると思います。

 こちらは RC 版なので Connect サイト(要登録)からダウンロードできます。

◆SAP ユーザ、ロール、グループ コネクタの RC 版(リリース候補版)
 こちらも RC 版です。これまでも SAP コネクタはありましたが、今後廃止される Web Service コネクタをベースに作られているものでした。今回のリリースは Web Service コネクタベースでは無いネイティブ版ということです。

 同じく Connect サイトからのダウンロードです。

◆Generic LDAP コネクタの更新
 以前正式リリースされた Generic LDAP コネクタの更新プログラムがリリースされています。
 LDAPS 接続での不具合修正や Apache Directory Server の新規サポートなどがポイントです。

 こちらは KB として公開されています。

なかなか時間が取れなくて Windows Azure Active Directory コネクタや SharePoint コネクタなど新規のコネクタの使い方を紹介できていませんが、順次公開していこうと思います。



2014年3月2日日曜日

祝!OpenID Connect ローンチ

遅ればせながら。OpenID Connectが2/27にローンチされました。

米OpenID Foundationを牽引してこられた崎村さんの6年に及ぶ努力が実を結んだ瞬間だったと思います。本当におめでとうございます。
 OpenID Connect リリース~インターネットのアイデンティティ層
 http://www.sakimura.org/2014/02/2277/

 OpenID Foundationが、パーソナルデータ流通時代を支えるアイデンティティAPI標準仕様「OpenID Connect」を発表
 http://www.openid.or.jp/news/2014/02/openid-connect-standard.html

このblogでもお伝えしてきたようにMicrosoftもWindows Azure Active DirectoryでOpenID Connect / OAuth をサポートしていますし、先日のVittorio Bertocci氏へのインタビューでも触れたOWIN(Open Web Interface for .NET)でもそれらの技術を利用できる様になっています。
 [WAAD] OpenID Connect Interop 5
 http://idmlab.eidentity.jp/2013/11/waad-openid-connect-interop-5.html

 [WAAD] OAuth2.0 への対応状況まとめ&ちょこっと OpenID Connect
 http://idmlab.eidentity.jp/2013/07/waad-oauth20-openid-connect.html

 開発者にとってのWindows Azure Active Directoryの役割と今後の展開
 http://www.buildinsider.net/enterprise/interviewvittorio/01

 OWIN(Open Web Interface for .NET)
 http://owin.org/


また、OpenIDファウンデーションジャパンの公式リリースでも触れられているように翻訳/教育ワーキンググループでOpenID Connectの仕様(実装ガイド)を翻訳しています。
- Basic Client
 http://openid-foundation-japan.github.io/openid-connect-basic-1_0.ja.html
- Implicit Client
 http://openid-foundation-japan.github.io/openid-connect-implicit-1_0.ja.html

私もImplicit側で少しだけお手伝いをさせていただきましたので、仕様を見てみたい、という方はぜひご覧ください。

ちなみに。
インターネットに関するプロトコルとか技術って全部アメリカからの輸入品だと思っていませんか?
少なくともIdentityに関しては日本は先進国であり、グローバルスタンダードを牽引している存在だと堂々と言えるんじゃないかな、と思えたのが今回の発表でした。
(少なくとも関わっている人たちは既に国境にとらわれていない方ばっかりですがw)