2014年5月21日水曜日

[AAD/ASP.NET] (続)OpenID Connectを使ってAADでログオンする~response_mode=fragment編

先日のポストの続きです。

前回はOWIN Security MiddlewareのOpenID Connectを使ってAzure Active Directory(AAD)でのログオンを行いました。
今回も基本的にやることは同じなのですが、OWINのOpenID Connectのresponse_modeの初期値がform_postなので、一般的なOpenID ConnectをサポートしたIdentity Providerへの流用の可能性を考えるために、Implicitフローで使われるfragmentを使ってid_tokenを受け渡す場合の工夫について試してみます。
※尚、現状AADではImplicitフローをサポートしているという表明があるわけではないので、今回紹介するのはあくまでImplicitもどきです。


■処理の流れとAADの場合
まず、OpenID ConnectにおけるImplicit Clientではどのような流れでid_tokenが発行されるのか?、AADではどうなるのか?についてみておきたいと思います。
 参考)OpenID Connect Implicit Client Implementer's Guide 1.0 - draft 15の日本語訳
    http://openid-foundation-japan.github.io/openid-connect-implicit-1_0.ja.html

大まかな流れは、以下のようになっています。

①Client は必要なリクエストパラメータを含んだ Authentication Request を構築する.
②Client は Authorization Server にリクエストを送信する.
③Authorization Server は End-User を認証する.
④Authorization Server は End-User の Consent/Authorization を取得する.
⑤Authorization Server は End-User を ID Token, およびもし要求されていれば Access Token とともに, Client に戻す.
⑥Client はそれらのトークンを検証し, End-User の Subject Identifier を取得する.


具体的には以下のような通信が行われます。

①~②クライアントからのAuthorizationリクエスト
https://server.example.com/authorize?
    response_type=id_token%20token
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid%20profile
    &state=af0ifjsldkj
    &nonce=n-0S6_WzA2Mj


response_typeにid_tokenおよびtokenを付けて要求を投げる必要がある(REQUIRED)、というのが仕様です。
しかし、現状でAADはresponse_typeにtokenをサポートしていないので、id_tokenだけを要求することにします。また、前述の通り、AADではresponse_modeの初期値がform_postなので、Implicit(もどき)の場合はresponse_mode=fragmentをつける必要があります。

結果、以下のようなリクエストになります。
https://login.windows.net/{tenantid}/oauth2/authorize?
    response_type=id_token
    &response_mode=fragment
    &client_id=xxxxx
    &redirect_uri=https%3a%2f%2flocalhost%3a44307%2fAccount%2fFragment%2f
    &scope=openid+profile
    &state=yyyyy
    &nonce=zzzzz



③~④End-Userの認証、同意取得
この部分は仕様のスコープ外なので手段は問いません。
AADではws-federationを使ってhttps://login.microsoftonline.comへ認証要求を投げ、ユーザ認証を行います。
https://login.microsoftonline.com/login.srf?
    wa=wsignin1.0
    &wtrealm=https%3a%2f%2flogin.windows.net%2f
    &wreply=https%3a%2f%2flogin.windows.net%2f{tenantid}%2fwsfederation
    &wctx=xxxx
    &wp=MBI_FED_SSL
    &id=


認証が成功するとhttps://login.windows.net/{tenantid}/wsfederationに対してSAMLトークンがPOSTされ、認証結果およびユーザ情報が渡されます。


⑤id_tokenをクライアントへ返す
HTTP302でredirect_uriへ戻します。その際、フラグメント(#)にid_tokenなど要求されたトークンを付加します。
HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
    access_token=SlAV32hkKG
    &token_type=bearer
    &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
    &expires_in=3600
    &state=af0ifjsldkj


AADの場合は、先ほどのリクエストでtokenを要求できませんでしたので、id_tokenのみが返ってきます。
HTTP/1.1 302 Found
  Location: https://localhost:44307/Account/Fragment/#
    id_token=eyJ0....
    &state=yyyyy
    &session_state=zzzzz



⑥返ってきたid_tokenを検証する
id_tokenがフラグメントで返ってきますので、UserAgent(ブラウザ等)上でパラメータを解析してクライアントへ送ってあげる必要があります。通常はJavaScriptでlocation.hashを解析してクライアントへid_tokenなどをPOSTしてあげます。
今回もredirect_uriに指定したページ(https://localhost:44307/Account/Fragment/)へのGETリクエストすると以下のようなJavaScriptを含むHTMLを返すようにしています。(テストなのでベタ書きしています)
<html>
<head>
    <meta name="viewport" content="width=device-width" />
    <title></title>
</head>
<body>
    <form method="post" name="autopost" action="https://localhost:44307/">
        <script type="text/javascript">
            var params = location.hash.substring(1).split('&');
            var id_token = params[0].substring(9);
            var state = params[1].substring(6);
            var session_state = params[2].substring(14);

            document.write("<input type=hidden name=id_token value=");
            document.write(id_token);
            document.write(" />");
            document.write("<input type=hidden name=state value=");
            document.write(state);
            document.write(" />");
            document.write("<input type=hidden name=session_state value=");
            document.write(session_state);
            document.write(" />");
        </script>
        <input type="submit" value="Submit" />
    </form>
    <script language="javascript">window.setTimeout('document.forms[0].submit()', 0);</script>
</body>
</html>




結果、フラグメントでわたってきたid_tokenがOWINのOpenID Connect Middlewareが動いているASP.NETアプリケーション(https://localhost:44307)へPOSTされ、自動的にトークン検証~ユーザ情報の取り出しを行ってくれます。


ここまでのフローをざっとシーケンスにしたものが以下の図です。



■ASP.NET/OWINでの実装
デフォルトのASP.NET/OWIN Middlewareではフラグメントでわたってきたid_tokenをUserAgent側で解析してPOSTする部分が用意されていないので、その部分だけは作ってあげる必要があります。
具体的にはViewを一つ用意して、そのエンドポイントに対するGETがあった場合に先のJavaScriptを含むHTMLを返すようにします。

以下の手順で実装しました。

ソリューション・エクスプローラからAccount Controllerへ新規MVC5 Viewを追加します。先のシーケンスの中にも出てきたように、今回はエンドポイントの名前を「Fragment」としています。



新規作成されたfragment.chtmlに先のJavaScriptを含むHTMLを記載します。



次に、Account Controllerにアクションを定義します。AccountController.csに以下のコードを追記します。
[AllowAnonymous]
public ActionResult Fragment()
{
    return View();
}



また、OWINの認証設定部分(Startup.Auth.cs)に以下の設定を入れます。
・response_type:id_token
・response_mode:fragmentを指定
・redirect_uri:先に追加したView(Fragment)のエンドポイントを指定

app.UseOpenIdConnectAuthentication(
    new OpenIdConnectAuthenticationOptions()
    {
        Client_Id = "xxxxx",
        Authority = "https://login.windows.net/{tenant}.onmicrosoft.com",
        Response_Type = "id_token",
        Response_Mode = "fragment",
        Redirect_Uri = "https://localhost:44307/Account/Fragment/",
        Description = new Microsoft.Owin.Security.AuthenticationDescription()
        {
            Caption = "Azure Active Directory",
            AuthenticationType = OpenIdConnectAuthenticationDefaults.AuthenticationType
        }
    });



これで実行すると前回と同じような動きに見えますが、裏側ではImplicit(もどき)でid_tokenが受け渡されます。

2014年5月7日水曜日

[AAD/ASP.NET] OpenID Connectを使ってAADでログオンする

先日の#idcon vol.18でAzure Active Directory(AAD)のOpenID Connect対応について話をしました。
遅ればせながらフォローアップをしていきたいと思います。

当日の資料はこちらです。



概要としては、OpenID Connectに対応(Preview)したAADに対して、こちらもPreview公開されたOWINのOpenID Connectセキュリティ・ミドルウェアを使ってASP.NETのMVC5のWebアプリケーションで接続(ログイン)してみる、ということをやってみます。
また、その過程でAADのOpenID Connect対応の特異点となっているresponse_modeパラメータの動きについても解説していきます。

少々長くなりそうなので、

  • 今回)素直にOWIN/OpenID ConnectでAADを使ってログオンする方法
  • 次回)一般的なOpenID Connect OPが対応しているresponse_mode="fragment"の場合に必要な工夫

という2回でお伝えしていきます。
また、その後になると思いますが、AAD以外のOpenID Connect OPへOWIN/OpenID Connectを使って接続する例についても解説していければと思います。


■設定方法と基本的な動作
一旦、基本的な設定と動作について確認していきます。中身のプロトコルの解説を細かくする前にまずは動きをつかんでもらうことが目的です。

◇Webアプリケーションの作成(ASP.NET MVC5)
・Visual Studioを起動し、ASP.NET/MVC5のWebアプリケーションを新規に作成します。

・NuGetを使いMicrosoft.Owin.Security.OpenIdConnectをインストールします。
 現状プレビュー版のパッケージなのでリリース前のパッケージを含めて、「openidconnect」で検索すると出てきます。


・SSLを有効にします。
 これはAADに設定するアプリケーションにはHTTPSが必須なため必要な設定です。
 ソリューションエクスプローラでプロジェクトのプロパティを開き、[SSL有効]をTrueに設定します。結果、自動的にSSLのURLが生成されます。


 次に、メニューより[プロジェクト]を選び[プロパティ]を開き、WebメニューからプロジェクトのURLを先ほど割り当てられたSSLのURLを設定し、保存します。



◇AADにアプリケーションの登録
・AADの管理画面へアクセスしアプリケーションの新規作成を行います。
 以下の設定を行います。
 ・実行する作業:組織で開発中のアプリケーションを追加


 ・アプリケーション情報  名前:任意
  種類:WEBアプリケーションやWEB API


 ・アプリケーションのプロパティ  サインオンURL:先ほどVisual Studioで作成したアプリケーションのURL(HTTPS)
  アプリケーションID/URI:任意(テナント内で一意)


 作成が完了したら構成メニューより割り当てられたクライアントIDをコピーしておきます。



◇Webアプリケーションの実装
・コードを書きます。
 ソリューションエクスプローラから、App_Start\Startup.Auth.csを開き、以下を追記します。
 usingディレクティブ
using Microsoft.Owin.Security.OpenIdConnect;

 Startupクラス
app.UseOpenIdConnectAuthentication(
new OpenIdConnectAuthenticationOptions()
{
   Client_Id = "AADに登録したアプリケーションのクライアントID",
   Authority = "https://login.windows.net/テナント名.onmicrosoft.com",
   Description = new Microsoft.Owin.Security.AuthenticationDescription()
   {
      Caption = "Azure Active Directory",
      AuthenticationType = OpenIdConnectAuthenticationDefaults.AuthenticationType
   }
});



 以上で準備は完了です。

◇Webアプリケーションの実行
・F5を押してアプリケーションを実行するとASP.NET MVC5のアプリケーションが起動しますので、右上のログインをクリックします。


・ログイン画面に遷移するので、右側に表示される[OpenIdConnect]をクリックします。


・AADのログイン画面に遷移するので組織のアカウントでログインします。


・ASP.NETアプリケーションにアカウントが存在しないので関連付けを行います。


 ちなみにこのアカウントはAspNetUsersテーブルに格納されますので、サーバエクスプローラから確認・編集ができます。

・ログインが完了し、ユーザ名が表示されます。



以上がとりあえず動くところまで、の手順です。
少ないコード量で実現できることがわかります。



■内部での通信シーケンスの解説
では、内部の動作について確認してみます。
細かく解説すると非常に面倒なフローなので、ざっくり解説すると以下の様になっています。

  1. AADの認可エンドポイントがws-federationのRPになっている
  2. 認証に関してはws-federationのSTSになっているhttps://login.microsoftonline.comで行われる(Federationされている)
  3. 認証が完了するとcodeとid_tokenが払い出される
  4. codeとid_tokenはUserAgent(ブラウザ)を経由し、HTTP POSTでclient(Webアプリケーション)へ渡される


この4番目のcodeやid_tokenのクライアントへの渡し方がOpenID Connectのresponse_modeというパラメータで決まってくるのですが、この流れを見るとAAD/OWINではform_postというタイプを使っていることがわかります。この部分がAADの特徴的な部分となっているので後ほど解説します。

以下が通信シーケンスの全体像です。




■response_modeとは
OpenID Connectの仕様を見ると本パラメータは以下の様に定義されています。

OPTIONAL. Authorization Endpoint からパラメータを返すために Authorization Server が使用する方法を通知する. 要求されるレスポンスモードがレスポンスタイプで指定されるデフォルトモードである場合, このパラメータの使用は推奨されない (NOT RECOMMENDED).
参考)http://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html


OpenID Connectにおいて、id_tokenをクライアント(Webアプリケーション)へ渡す方法は、Authorization Codeフローではcodeと引き換えにresponse bodyで、Implicitフローではフラグメント(URLの後の#以下)でというのが標準的?です。
しかし、先の通信シーケンスをみるとわかるようにAAD/OWINではid_tokenをJavaScriptで自動的にクライアントへPOSTするようなフォームを含むHTMLをUserAgentへ返すことで、id_tokenをクライアントへ渡しています。この方法(response_mode)をform_postと呼びます。
現状、AADにおけるresponse_modeはこのデフォルトのform_postおよびfragment(Implicitで使われる)およびquery(GETパラメータで渡す)の3つがサポートされます。
一般的にサーバサイドでパラメータの横取りをすることが出来ないfragmentを使ってtokenを渡すのが基本なのですがOAuthにおけるaccess_tokenのようにBearer Token(トークンを持っている人なら認可する)ではなくHok Token(トークンを持っている人が本当に持ち主なのかを確認してから認可する)であるOpenID Connectのid_tokenならそこまで気を遣わなくても大丈夫、という考え方なのかも知れません。
また、これは#idconでも話したように推測でしかないのですが、これまでASP.NETがサポートしてきたws-federationやSAML-Pなどのプロトコルと同じ動きをさせることでミドルウェアの実装を簡素化する、というのが真相なのかも知れません。(ws-federationやSAML-PではSAMLトークンをUserAgentを経由してRPへPOSTして渡すのが最近の主流なので)


ただ、現在のOWINの実装では他のOpenID Connect OP(現状あまりresponse_mode自体をサポートしているOPが少なく、かつform_postをサポートしているところはほぼない)との相互接続に問題が起きやすいので、response_mode="fragment"で構成されたOPをASP.NET/OWINで使う場合にどうすれば良いのか、について次回解説したいと思います。


2014年4月24日木曜日

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

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

パターン認証ID管理
クラウドのアイデンティティを使うAzure ADAzure 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と絡めたオンプレミスとクラウドのハイブリッド・シナリオが強く意識されていますね。
詳細情報が楽しみです。

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