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で使う場合にどうすれば良いのか、について次回解説したいと思います。