WebSurfer's Home

トップ > Blog 1   |   ログイン
APMLフィルター

ASP.NET Identity タイムアウト判定

by WebSurfer 2020年10月23日 18:22

先の記事「Forms 認証のタイムアウト判定」の ASP.NET Identity 版です。(Core ではなく .NET Framework 用の ASP.NET Identity です。Core 3.1 版は別の記事「ASP.NET Core Identity タイムアウト判定」に書きました)

有効期限切れの通知

Visual Studio 2019 などのテンプレートを使って ASP.NET Web アプリのプロジェクトを作る際、認証を「個別のユーザーアカウント」に設定すると ASP.NET Identity を利用したユーザー認証が実装されます。

基本的には旧来のフォーム認証と同様で、ログイン後はクッキーに認証チケットを入れて要求毎にサーバーに送信するので認証状態が継続されるという仕組みになっています。

そこで、一旦認証を受けたユーザーがログオフせずブラウザを立ち上げたまま長時間席を外すなどして、タイムアウトに設定した時間を超えてアクセスしなかった場合を考えてください。

ユーザーが席に戻ってきて再度アクセスした場合、アクセスしたページが匿名アクセスを許可してなければ、ログインページにリダイレクトされます。

その際、ユーザーに認証チケットが期限切れとなっていることを知らせるためにどのようなことができるかということを書きます。

User.Identity.IsAuthenticated ではダメです。認証されているか否かは判定できますが、認証チケットが期限切れになったのか、それとも最初からログインしてなかったのかはわかりませんから。

一旦認証を受けたが、認証チケットが期限切れになっているというのは、Web サーバー側では以下の条件で判定できるはずです。

  • 要求 HTTP ヘッダーに認証クッキーが含まれる。
  • 認証クッキーの中の認証チケットが期限切れ。

認証クッキーと認証チケットは違うことに注意してください。クッキーはチケットの入れ物に過ぎません。認証チケットの有効期限は認証クッキーの Value の中に入っている情報の一つです。HttpCookie.Expires ではありません。

一般的に、一旦認証クッキーの発行を受ければ、ブラウザを閉じない限り次の要求の時にブラウザはサーバーにクッキーを送ります。(注:認証クッキーを「永続化」している場合は話が違ってきます。詳しくは別の記事「Froms 認証クッキーの永続化」を見てください)

Web サーバーが認証クッキーを取得できれば、その Value を復号して認証チケットを取得し、期限切れか否かの情報を取得できます。それで上記の 2 つの条件を確認できます。

しかし、認証クッキーを復号する方法が旧来のフォーム認証の場合とは全く異なっているのが問題でした。そこは、ググって調べた記事 ASP.NET Identity 2.0 decrypt Owin cookieReading Katana Cookie Authentication Middleware’s Cookie from FormsAuthenticationModule を参考にさせていただきました。

記事のコードでは MemoryStream などを使って ClaimsIdentity などを取得していますが、前者の記事のコメント欄に書いてあるように TicketSerializer クラスの Deserialize メソッドを使って AuthenticationTicket オブジェクトを取得し、それから必要な情報を得る方が良さそうです。

と言うより、認証チケットが有効期限切れかどうかは、AuthenticationTicket.Properties で取得できる AuthenticationProperties の ExpiresUtc プロパティをチェックしないと分からないので、そうせざるを得ないようです。

コードは以下のように HTTP モジュールとして実装してみました。上の画像がこのモジュールにより認証チケットの期限切れをチェックして Login 画面上でユーザーに通知したものです。

ただし、ユーザーへの通知を下のコードの最後の方にあるように Response.Write を使って書き込んだ場合、見かけは上の画像のようになりますが、実は <html></html> タグの外(この例では先頭)に書き込まれています。

なので、ユーザーへの通知が必要なら、HTTP モジュールで通知を行うのではなく、Login ページに下のようなコードを含めて判定し、ページの所定の位置に書き込むようにする方がよさそうです。

using System;
using System.Linq;
using System.Web;
using System.Security.Claims;
using Microsoft.Owin.Security;
using Microsoft.Owin.Security.DataHandler.Serializer;

namespace Mvc5ProfileInfo.Modules
{
    public class MyHttpModule : IHttpModule
    {
        // IHttpModule に Dispose メソッドが含まれるので定義が必要
        public void Dispose()
        {
            
        }

        public void Init(HttpApplication context)
        {
            context.AuthenticateRequest += Context_AuthenticateRequest;
        }

        private void Context_AuthenticateRequest(object sender, EventArgs e)
        {
            HttpRequest request = HttpContext.Current.Request;

            // 認証チケットの期限が切れた後、認証が必要なページにアクセス
            // して Login ページにリダイレクトされた時のみ対応します。
            // "/Account/Login" は実際に合わせて適宜変更してください
            if (request.CurrentExecutionFilePath != "/Account/Login")
            {
                return;
            }

            // 認証クッキーが送られてくる時のみ対応します。クッキー名の
            // .AspNet.ApplicationCookie はデフォルト。必要あれば変更
            HttpCookie cookie = request.Cookies.Get(".AspNet.ApplicationCookie");
            if (cookie == null) 
            { 
                return; 
            }

            // (注1)・・・下の注記参照
            string ticket = cookie.Value;
            ticket = ticket.Replace('-', '+').Replace('_', '/');

            int padding = 3 - ((ticket.Length + 3) % 4);
            if (padding != 0)
            {
                ticket = ticket + new string('=', padding);
            }

            byte[] bytes = Convert.FromBase64String(ticket);

            // (注2)・・・下の注記参照
            bytes = System.Web.Security.MachineKey.Unprotect(bytes,
                "Microsoft.Owin.Security.Cookies.CookieAuthenticationMiddleware",
                "ApplicationCookie", "v1");

            TicketSerializer serializer = new TicketSerializer();
            AuthenticationTicket authTicket = serializer.Deserialize(bytes);

            // 以下いろいろ書いてあるが必要なのは AuthenticationProperties
            // オブジェクトの ExpiresUtc プロパティで取得できる有効期限。
            // 他はその他にもいろいろ情報が取得できることを示したのみ
            ClaimsIdentity identity = authTicket.Identity;
            AuthenticationProperties property = authTicket.Properties;

            if (identity != null && property != null)
            {
                ClaimsPrincipal principal = new ClaimsPrincipal(identity);

                // クッキーが送られてくると有効期限が切れていても
                // ClaimsIdentity.IsAuthenticated は true になる
                bool isAuthenticated = identity.IsAuthenticated;
                string UserName = identity.Name;
                string authType = identity.AuthenticationType;

                // 追加したプロファイル情報 HandleName の取得
                Claim claim = identity.Claims.
                        FirstOrDefault(c => c.Type == ClaimTypes.GivenName);
                string handleName = claim.Value;

                // ExpiresUtc と現在の時刻を比較して期限切れか否かを判定
                DateTimeOffset? expiersUtc = property.ExpiresUtc;
                if (expiersUtc.Value < DateTimeOffset.UtcNow)
                {
                    // 知らせるための処置を書く
                    // 以下のコードでは <html></html> 外に書き込まれるので注意
                    HttpContext.Current.Response.Write("<h1><font color=red>" +
                      handleName +
                      " さん、認証チケットの有効期限が切れています" +
                      "</font></h1><hr>");
                }
            }
        }
    }
}

(注 1) 認証チケットのバイト列をクッキーに設定する際 Base64 でエンコードされますが、その際 URL アプリケーションのための変形が行われ '+' は '-' に、'/' は '_' に変換され、パディング '=' は除去されます。エンコードには ITextEncoder.Encode Method (Byte[]) が使われているようです。なので、そのデコードには ITextEncoder.Decode Method (String) を使えば文字列を変換するコードを書かなくてもバイト列を取得できます。具体的には以下の通りです(検証済み)。

byte[] bytes = Microsoft.Owin.Security.DataHandler.Encoder.
               TextEncodings.Base64Url.Decode(cookie.Value);

(注 2) 認証チケットのバイト列は MachineKey.Protect(Byte[], String[]) メソッドを使って暗号化されているようです。復号するには MachineKey.Unprotect(Byte[], String[]) メソッドを使いますが、その際、第 2 引数には暗号化するときに Protect メソッドで使用した値と同じものを設定する必要があります(違うと CryptographicException がスローされます)。

では、その第 2 引数は何になるかですが、自分が探した限りでは Microsoft の公式文書は見つかりませんでした。ググって見つかった記事の中で一番詳しかったのが「ASP.NET Cookie是怎么生成的」で、それによると以下のようにするのと同じになるようです(検証済み)。

string purpose1 = typeof(Microsoft.Owin.Security.Cookies.
                         CookieAuthenticationMiddleware).FullName;
string purpose2 = Microsoft.AspNet.Identity.
                  DefaultAuthenticationTypes.ApplicationCookie;
string purpose3 = "v1";
bytes = System.Web.Security.MachineKey.Unprotect(bytes, 
                                    purpose1, purpose2, purpose3);

(注 3)上に書いた HTTP モジュールを動かすには web.config での登録が必要です。その具体例は以下の通りです。

<system.webServer>
  <modules>
    <add name="MyHttpModule" type="Mvc5ProfileInfo.Modules.MyHttpModule"/>
  </modules>
</system.webServer>

Tags: , ,

Authentication

基本認証

by WebSurfer 2015年11月23日 14:19

IIS7 で基本認証を行う際のブラウザとサーバーのやり取りを調べましたので備忘録として書いておきます。

基本認証のやり取り

上の画像は IIS7 と IE9 で基本認証を行った場合の要求 / 応答を Fiddler2 でキャプチャしたものです。

  1. 最初の要求に対してはサーバーから応答ヘッダに WWW-Authenticate: Basic realm="xxx" を含む HTTP 401 応答が返ってきます。上の画像の #2 がそれです。xxx には IIS7 の場合ホスト名が入ります。
  2. ブラウザはそれを受けてユーザーに[ユーザー名]と[パスワード]の入力を促すダイアログを表示します。
  3. ユーザーがダイアログに[ユーザー名]と[パスワード]を入力して[OK]ボタンをクリックすると、ブラウザは 1 で要求したページを再度 GET 要求します。上の画像の #3 がそれです。
  4. その際、ブラウザは認証用のヘッダ Authorization: Basic UGFwaWt...(上の画像で赤枠で囲った部分を見てください)をサーバーに送ります。UGFwaWt... の部分は[ユーザ名]と[パスワード]をコロン ":" でつなぎ Base64 でエンコードしたものです。
  5. サーバーはこのヘッダを見てユーザーを認証し、HTTP 200 ステータスコード(成功)と共に要求されたコンテンツをブラウザに送信します。
  6. これ以降、ユーザーがブラウザを閉じない限りホスト名 xxx に対しては認証用のヘッダ(画像で赤枠で囲ったものと同じ)が要求ヘッダに含まれて送信され、要求のたび自動的に認証が行われるようになります。上の画像の #4, #5 がそれです。

以上、基本認証でのブラウザとサーバーのやり取りを簡単にまとめてみました。

フォーム認証と Windows 認証の場合は、それぞれ先の記事「Forms 認証のログイン・ログオフ動作」と「非ドメインユーザーの誘導」に書きましたので興味がありましたら見てください。

Tags: ,

Authentication

パススルー認証

by WebSurfer 2015年9月13日 16:29

IIS マネージャーで[サイトの編集]を行う際、下の画像(Vista の IIS7 のものです)のように「パススルー認証」という言葉が出てきますが、これは一体何かという話を書きます。

パススルー認証

まず、そもそもパススルー認証とは一般的にどういう意味かですが広義には以下のようなことらしいです。

例えば、サーバー A とサーバー B の 2 つのサーバーがあり、サーバー B のみにユーザーの資格情報が保持されているとします。

クライアントがサーバー A にアクセスした際、サーバー A ではユーザー認証ができないので、サーバー A はサーバー B にユーザー認証を要求します。そのようなメカニズムをパススルー認証 (Pass-Through Authentication) と呼んでいるそうです。

MSDN の記事 Pass-Through Authentication の Figure 1 を見て、Active Directory ドメインサービス環境で統合 Windows 認証を使用している場合を考えると理解しやすいかもしれません。

で、それと上の画像の「パススルー認証」とどういう関係があるのかですが、それについては「サイトの編集」ダイアログのヘルプ(右上の ? ボタンをクリックすると表示される)に以下の説明があります。

"必要に応じて、[接続] をクリックして、物理パスに接続するための資格情報を指定することもできます。 資格情報を指定しない場合、Web サーバーはパススルー認証を使用します。 これは、コンテンツにはアプリケーション ユーザーの ID を使用してアクセスし、構成ファイルにはアプリケーション プールの ID を使用してアクセスすることを意味します。"

注意 1:
上で「コンテンツにはアプリケーション ユーザーの ID を使用」とありますが、これは統合 Windows 認証の環境でパススルー認証によってユーザー認証が完了した場合で、匿名認証の場合は IUSR が使用されます。また、「コンテンツ」というのは静的コンテンツのみです。(動的コンテンツについては下の注意 3 参照)

注意 2:
上で言う「構成ファイル」とは web.config のことです。物理パス C:\inetpub\wwwroot には自動的にアプリケーションプール ID が適切なアクセス権を持つように設定されます(正確には、Microsoft TechNet の記事 に書いてあるように、wwwroot フォルダに対して必要なアクセス権を持つ IIS_IUSRS グループが設定されます。そして、実行時にアプリケーションプール ID のアクセストークンに対して IIS_IUSRS メンバーシップが自動的に追加されるので web.config には問題なくアクセスできます)。

ただし、物理パスが C:\inetpub\wwwroot 以外にある場合は要注意です。特に、物理パスが UNC にあって web.config も UNC にある場合がややこしいです(詳しくは Microsoft Support の記事 を見てください)。

注意 3:
.aspx, .ascx などの動的コンテンツへのアクセス、.aspx.cs, .ascx.cs などコードビハインドのコードでのファイルや SQL Server へのアクセスは「アプリケーション プールの ID を使用」します。

この場合、先の記事 で書きましたように Temporary ASP.NET Files フォルダーにコンパイル済みアセンブリが置かれますので、アプリケーション プールの ID はそのフォルダに対しても適切なアクセス権を持つ必要があります。(自動的に設定されているはず)

なお、.aspx ページの中に外部スクリプトファイルや外部 CSS ファイルなど静的ファイルを取り込むための定義(例: <script src="/scripts/jquery.js" ...)がされていて、.aspx ページがブラウザに読み込まれた後、ブラウザがそれらの静的ファイルをサーバーに要求した場合は、上で言う「コンテンツにはアプリケーション ユーザーの ID を使用」が当てはまりますので注意してください。ただし、HTTP ハンドラ経由で静的ファイルを取得する場合(例:HTTP ハンドラでキャッシュコントロール)は話は別で「アプリケーション プールの ID を使用」します。

さらに、「サイトの編集」ダイアログ上の [接続] をクリックすると表示される「接続」ダイアログのヘルプには [アプリケーション ユーザー (パススルー認証)] に対して以下の説明がされています。

"このオプションは、パススルー認証を使用する場合に選択します。 このオプションを選択すると、物理パスへのアクセスに要求元のユーザーの資格情報が使用されます。

匿名要求については、匿名認証用に構成されている ID が物理パスへのアクセスに使用されます。 既定では、この ID は組み込みの IUSR アカウントです。

認証された要求の場合、物理パスへのアクセスに要求元のユーザーの認証済み資格情報のセットが使用されます。 このアプリケーションで使用されるアプリケ��ション プール ID は物理パスに対して読み取りアクセス権を持ち、認証されたユーザーが、物理パス上のコンテンツにアクセスできるようにします。"

・・・という訳で、「接続」ダイアログのパス資格情報で [アプリケーション ユーザー (パススルー認証)] を選択するということは、

  1. 匿名アクセスの場合は IUSR、(デフォルト。IUSR は変更可能
  2. Winsows 認証の場合はログインしたユーザーの Windows アカウント、
  3. Forms 認証でユーザーがログイン済みの場合の場合アプリケーションプール ID(例:IIS7 では NETWORK SERVICE。ASP.NET の ID オブジェクト 参照)

の資格情報で「サイトの編集」ダイアログで [物理パス(P):] に設定したパスのコンテンツにアクセスすることになり、統合 Windows 認証を利用している場合は上に述べたパススルー認証のメカニズムによってユーザーの資格情報をドメインコントローラーから取得してコンテンツにアクセスすることになるはずです。

従って、通常は IIS のデフォルトの設定どおりパススルー認証としておけば、統合 Windows 認証に限らずほとんどのケースで問題なさそうです。

なお、「サイトの設定」ダイアログで [テスト設定(G):] をクリックすると、「テスト接続」ダイアログに [結果(R):] が 2 つ表示され、前者は OK ながら、後者の方に "パス (C:\xxx\yyy) へのアクセスを検証できません。" と表示されて問題ありそうな感じがしますが、それは気にしなくてよさそうです。

テスト接続

前者は ( ) 内に示す ID が有効かどうか、後者はパススルー認証で物理パスへのアクセス権があるかどうかの結果を表示しているようですが、IIS マネージャーが検証できないだけで、実際にアクセス権がないと言っているわけではなさそうですので。

------------

ところで、一番上の画像の「接続」ダイアログで [特定のユーザー(U):] を指定した場合ですが、それついてはまだよく分かってないです。(汗)

物理パスへのアクセスが指定したユーザーのアクセス権で行われるのは間違いなさそうです。

ただし、特定のユーザーを指定することによって、web.config にそのユーザーの偽装が設定されるとか、匿名アクセスの資格情報が IUSR から変更になるということはなかったです。

また、フォーム認証でのログイン操作の際に "System.Data.SqlClient.SqlException: ユーザーにはこの操作を実行する権限がありません。" というエラーが出てログインできなくなるという問題が出るなど、訳がわからないところもあります(App_Data の ASPNETDB.mdf へのユーザーインスタンスへの接続ですが、資格情報の問題ではなさそう。他の DB のユーザーインスタンスには接続できたので)。

今後の課題ということで、分かったらまたこの記事に追記することにします。

Tags: ,

Authentication

About this blog

2010年5月にこのブログを立ち上げました。主に ASP.NET Web アプリ関係の記事です。

Calendar

<<  2024年5月  >>
2829301234
567891011
12131415161718
19202122232425
2627282930311
2345678

View posts in large calendar