認証と承認について

Question

 

皆さん、こんにちは。

今回、webシステムの構築についてお伺いしたいことがあります。

 

件名のとおり、認証と承認なのですが、今回以下のようなことを要求されています。

 

１．ユーザーを分別すると（ロール？）、管理者とメンバーに二分される。

２．メンバーはすべて同じページにアクセスできる。

３．管理者は複数人いて、管理者には、a.最高管理者　b.一般管理者が存在します。

４．最高管理者はすべてのページにアクセスできる。

５．一般管理者は、最高管理者が設定したページにしかアクセスできない。

 

以上のような認証と承認となり、各管理者のアクセス許可はデータベースに保存する。

また、ログイン後のメニューは、アクセスが許可されたページのみとなり、DBから取得する。

 

ちょっと、質問しづらい内容なので、不明な点があれば言ってください。（日本語が下手ですみません。）

 

このような場合、皆さんはどのように実装されているのでしょうか？

アドバイス、参考になるサイトがあれば、ご教授ください。

 

 

 

Answer 1

ASP.NET2.0 標準の MemebershipProvider とRoleProvider で実現できると思いま

すが、それはスタディされたのでしょうか？　それでは何か不都合なことがあるので
しょうか？

Answer 2

ブロンコさん　こんにちは

ブロンコ さんからの引用

１．ユーザーを分別すると（ロール？）、管理者とメンバーに二分される。 ２．メンバーはすべて同じページにアクセスできる。 ３．管理者は複数人いて、管理者には、a.最高管理者　b.一般管理者が存在します。 ４．最高管理者はすべてのページにアクセスできる。 ５．一般管理者は、最高管理者が設定したページにしかアクセスできない。   以上のような認証と承認となり、各管理者のアクセス許可はデータベースに保存する。 また、ログイン後のメニューは、アクセスが許可されたページのみとなり、DBから取得する。

ブロンコさんの要件だと、任意の(管理者用?)ページに対して最高管理者が一般管理者に対してアクセス

制御を動的に行えるということですか？どのようなシステムなのかわかりませんが...

 

ブロンコさんがロールなどをどのように実現するつもりか、ページ構成はどうなっているのか等わからないので

参考になるかわかりませんが、ページのパスとロールのみでアクセス制御するという条件なら、Pageクラスを

継承したすべてのWebフォームの基本クラスを作成して、そのページのOnLoadやOnInitや対応するイベントで、

リクエストされたパスとユーザのロールでアクセス権の制御をしてやるようにすればよい気がします。

 

メニューはどんなメニューを実現したい(するつもりなのか)のか、サイトがどのような構成なのか、わからないのでなんともいえませんが、汎用的につくるのならSiteMapProviderを実装すればよいのではと思います。

 

 

Answer 3

SurferOnWww さんからの引用

ASP.NET2.0 標準の MemebershipProvider とRoleProvider で実現できると思いま すが、それはスタディされたのでしょうか？　それでは何か不都合なことがあるので しょうか？

 

それらについては、まだ勉強しておりません。・・・というか、知らなかったです。

一度調べてみます。

Answer 4

こんにちは、handcraftさん。

 

handcraft さんからの引用

ブロンコさんの要件だと、任意の(管理者用?)ページに対して最高管理者が一般管理者に対してアクセス 制御を動的に行えるということですか？どのようなシステムなのかわかりませんが...

 

そのとおりです。最高管理者がアクセス制御ページにて動的に変更できるようになります。

 

handcraft さんからの引用

ブロンコさんがロールなどをどのように実現するつもりか、ページ構成はどうなっているのか等わからないので 参考になるかわかりませんが、ページのパスとロールのみでアクセス制御するという条件なら、Pageクラスを 継承したすべてのWebフォームの基本クラスを作成して、そのページのOnLoadやOnInitや対応するイベントで、 リクエストされたパスとユーザのロールでアクセス権の制御をしてやるようにすればよい気がします。

 

サイトのルートディレクトリには、一般公開用のwebページとログインページがあります。

１．認証が通ると、Membersというディレクトリへのアクセスが可能になります。

２．ログイン後は、DBからアクセス可能なページのメニューを動的に表示します。（実際はセッションに格納したデータ）

３．メンバーはDBに登録されているメニューテーブルより、該当するロールのメニューを取得し、

　　一般管理者は最高管理者が設定したメニューを登録しているテーブルよりメニューを取得します。

　　（最高管理者は、すべてのメニューを取得しています）

４．各ページへのアクセスチェックは、MasterPageのPage_Initでチェックを行ってます。

５．承認されていなければ、エラーページに飛ばします。

 

以下、web.configです。

ルートディレクトリのweb.config

Code Snippet

    <sessionState mode="InProc" cookieless="false" timeout="20" />
    <authentication mode="Forms">
      <forms name="formauth" loginUrl="Login.aspx" protection="All" timeout="20" path="/"></forms>
    </authentication>
    <authorization>
      <allow users="*"/>
    </authorization>

 

Membersディレクトりのweb.config

Code Snippet

      <authorization>
        <deny users="?"/>
      </authorization>

 

 

となっており、１．の認証でFormsAuthenticationTicketを発行しています。

このチケットのUserDataにアクセス可能なURLを格納し、セッションにもメニューを入れております。

このセッションは、メニュー作成の為に保存しています。

４．の承認では、HttpContext.Current.User.IsInRoleを使ってリクエストがあったURLのチェックを行います。

 

この承認のところで、チケットは有効だけどセッションが切れていて、メニューがないのに、Membersページに

アクセスできたり、セッションからデータを取得するとNullになってたりと、します。

チケットとクッキーのtimeoutを一緒にしているのですが・・・

すべてセッションで行えばいいような気もするのですが、せっかく認証チケットというものがあるので、

これをどうにかして使えないかなと思ってます。

クッキーを使えれば、今後クッキーの有効期間を長くすればログインしなくてもいいようになるかと。

handcraft さんからの引用

メニューはどんなメニューを実現したい(するつもりなのか)のか、サイトがどのような構成なのか、わからないのでなんともいえませんが、汎用的につくるのならSiteMapProviderを実装すればよいのではと思います。

 

SiteMapProviderは知らなかったです。ちょっと調べてみたいと思います。

 

以上、指摘があればよろしくお願いします。

Answer 5

ブロンコ さんからの引用

それらについては、まだ勉強しておりません。・・・というか、知らなかったです。 一度調べてみます。

 

それでは以下の Web が参考になるかもしれません。

 

http://msdn.microsoft.com/ja-jp/library/91f66yxt.aspx

ASP.NET Web サイトのセキュリティ

 

手っ取り早く理解するには、まずチュートリアルをやってみる方がいいかもしれ
ませんね。

 

http://msdn.microsoft.com/ja-jp/library/879kf95c.aspx

チュートリアル : メンバシップとユーザー ログインを使用する Web サイトの作成

 

http://msdn.microsoft.com/ja-jp/library/t32yf0a9.aspx

チュートリアル : ロールによる Web サイトユーザーの管理

 

「ログイン後のメニューは、アクセスが許可されたページのみとなり」というのは

以下の Web を参考にトリミング機能を実装すれば可能になると思います。

 

http://www.atmarkit.co.jp/fdotnet/dotnettips/513aspsectriming/aspsectriming.html

ナビゲーション・コントロールでセキュリティ・トリミング機能を有効にするには？

Answer 6

 

SurferOnWww さん、こんにちは。

 

参考サイトありがとうございました。

最初の4つは、以前参照したことがありました。

最後のURLは初めてなので、読ませていただきました。

 

それらのサイトでは、あるユーザーには、ロールが割り当てられており、そのロールについて

アクセス可能ページがもうけられているようですね。

今回の要件は、一般管理者は、最高管理者が動的に設定したページにしかアクセスできないように

しないといけません。

ロールベースでアクセス権が設定されており、最高管理者が一般管理者のロールを変更するような

要件なら可能かと思います。

 

他の案件で、ロールベース管理ならこの方法で実装しようかと思います。

最後のサイトは初めてだったので、とても勉強になりました。

 

Answer 7

ブロンコ さんからの引用

今回の要件は、一般管理者は、最高管理者が動的に設定したページにしかアクセスできないように しないといけません。

 

承認の条件が動的に変わると言うわけですね。それは全く想定外でした。（汗）

 

メニューの表示だけなら handcraft さんのレスにある SiteMapProvider を使って

何とかなりそうな気がしますが、当然、アクセス制限もかけるというのが条件な

んでしょうね。

 

とすると、先のレスで紹介した方法では、Web.config の authorization 要素を

動的に書き換えてやるなどしないダメそうですが、そのような方法があるのか

どうか自分には分かりません。お役に立てず、すみません。

Answer 8

ブロンコ さんからの引用

４．の承認では、HttpContext.Current.User.IsInRoleを使ってリクエストがあったURLのチェックを行います。   この承認のところで、チケットは有効だけどセッションが切れていて、メニューがないのに、Membersページに アクセスできたり、セッションからデータを取得するとNullになってたりと、します。 チケットとクッキーのtimeoutを一緒にしているのですが・・・ すべてセッションで行えばいいような気もするのですが、せっかく認証チケットというものがあるので、 これをどうにかして使えないかなと思ってます。 クッキーを使えれば、今後クッキーの有効期間を長くすればログインしなくてもいいようになるかと。

セッションが切れれば認証チケットも無効になったようなきがするのですが。

（確認していないので、まちがってたらごめんなさい)

 

認証を自前でやって認証クッキーをFormsAuthentication.RedirectFromLoginPage("..",true)のようにして

永続化するようにしているわけではないのですよね？

 

クッキーの有効期間を長くすることがよいか悪いか条件、要求によるんでしょうけど、クッキーの有効期間を延ばして、

セッションが切れてから、アドレスを直接指定されてアクセスされまた、そのような操作を許す場合、必要なセッション

の情報を構築するのは開発者の責任かなと思います。

MasterPageでPage.Session.IsNewSessionがtrueの場合メニュー用のデータを構築するようにすれば対応できる

気がしますが。

Answer 9

SurferOnWww さん、ありがとうございます。

そう、承認の条件が動的にかわるんですよ。これがなければ、なにも問題ないのですがね。

Web.config の authorization 要素の書き換えですが、できないこともなさそうなんですが、あまりよろしくなさそうなんで、やめときます。

 

handcraft さん、おはようございます。

handcraft さんからの引用

認証を自前でやって認証クッキーをFormsAuthentication.RedirectFromLoginPage("..",true)のようにして 永続化するようにしているわけではないのですよね？

Code Snippet

 

        FormsAuthenticationTicket ticket= new FormsAuthenticationTicket(
            1,
            "ログインメンバー",
            DateTime.Now,
            DateTime.Now.AddMinutes(20),
            true,
            string.Join("|", rolesArray)
            );

        HttpCookie cookie = new HttpCookie(
            FormsAuthentication.FormsCookieName,
            FormsAuthentication.Encrypt(ticket));

        cookie.Path = FormsAuthentication.FormsCookiePath;
        Response.Cookies.Add(cookie);

 

ログイン時のソース

 

Code Snippet

 

    protected void Application_AuthenticateRequest(object sender, EventArgs e) {
       
        HttpCookie cookie = Context.Request.Cookies[FormsAuthentication.FormsCookieName];

        if(cookie == null)
            return;

        // 復号化する
        FormsAuthenticationTicket ticket = null;
        try {
            ticket = FormsAuthentication.Decrypt(cookie.Value);
        } catch(Exception ex) {
        }

        if(ticket == null)
            return;

        // UserDataプロパティに格納されているロール情報を参照する
        string role = ticket.UserData;

        // フォーム認証ではIPrincipalオブジェクトにGenericPrincipalクラス
        // が利用される。このクラスは、資格情報を表すFormsIdentityクラスと
        // ロール情報（string[]オブジェクト）から構成される
        FormsIdentity identity = new FormsIdentity(ticket);
        string[] roles = ticket.UserData.Split(char.Parse("|"));
       
        System.Security.Principal.GenericPrincipal principal =
            new System.Security.Principal.GenericPrincipal(identity, roles);

        // FormsIdentityオブジェクトをContext.Userに代入すると
        // Page.Userから参照可能になる
        HttpContext.Current.User = principal;
        System.Threading.Thread.CurrentPrincipal = HttpContext.Current.User;

                
    }

 

Global.asaxのクッキー復元コードです。

現在の認証はこんな感じで実装しています。

 

handcraft さんからの引用

クッキーの有効期間を長くすることがよいか悪いか条件、要求によるんでしょうけど、クッキーの有効期間を延ばして、 セッションが切れてから、アドレスを直接指定されてアクセスされまた、そのような操作を許す場合、必要なセッション の情報を構築するのは開発者の責任かなと思います。 MasterPageでPage.Session.IsNewSessionがtrueの場合メニュー用のデータを構築するようにすれば対応できる 気がしますが。

てことは、認証が生きているのに、セッションデータがクリアされている場合は、必要な情報を再構築しないといけないってことですよね？ちょっとやってみます。がしかし、これはどのタイミングがいいのでしょうか？MasterPageのPage_Initイベントで実装すればいいのでしょうか？

 

IsNewSessionについては、しらべて挑戦してみます。

Answer 10

ブロンコさん　こんにちは。

 

詳しいコードを掲載していただきありがとうございます。

認証情報の作成の復元を自前で行っているのですね。てっきりフレームワークで提供される仕組みを利用していたと思っていたので話がかみ合っていなかった部分もあったかもしれません。

 

で、クッキーが永続可される理由はAPIヘルプを見るとコンストラクタでFormsAuthenticationTicketに引数にtrueを渡している部分が原因だと思います。

 

FormsAuthenticationTicket コンストラクタ

http://msdn.microsoft.com/ja-jp/library/kybcs83h.aspx

 

セッション情報を作成する場所はMasterPageで認証を行っていると記載があったので、その後やればよいのかなと思って気軽に書いてしまったのですが。もっと適切な場所があるのかもしれません。

Answer 11

 

handcraft さん、こんにちは。

 

コードを読んでいただいてありがとうございます。

ご指摘の通り、isPersistent　にtrueが設定していました。これをとりあえずfalseにしてみます。

 

で、こういう認証と承認の要件では、この実装方法というかシステム設計は正しい方法なのでしょうか？

なにが正しいってないとは思うのですが、一般的な方法はあるのでしょうか？

 

こういった要件を要求されて、構築された方がおられたら、アドバイスください。

Answer 12

こんにちは

 

私程度の経験では一般的なことはかたれませんが、実際のところシステムの要件やクライアント(マシンではありません)の

環境によってさまざまだと思います。ブロンコさんのシステムをそのように認証するようにした経緯もあるでしょうし。動的にページのアクセス権限が変わる場合は、ベースページやブロンコさんがマスターページでやられているように特定の場所で権限チェックのコードを書くのが一番手っ取り早い気もします。

 

一般論になりますが、ASP.NET2.0でフォーム認証用に新たに提供されたのはLoginコントロールを使った認証です。組み込みのプロバイダがうまく使えるというのは実際はそうないと思いますがメンバシッププロバイダを設定するとそのまま便利に使えたります。LoginコントロールのAuthenticateイベントを使用してユーザを認証する部分だけ、独自で行い、認証クッキーの作成はFormsAuthenticateクラスのSetAuthCookieやReDirectFromLoginPageメソッドに任せることが多いのかなと思います。(あくまで私の経験上は、です)

単純に、認証クッキーなどを使用せずにユーザ情報、ロール情報をセッションに格納しているだけというのもあると思います。

さらにロールプロバイダを使用できるようにするとロールの管理もできるようになります。これも組み込みのプロバイダがそのまま使えることはそうないのかなと思いますが。ブロンコさんがやっているような方法でロールを設定することもできます。ロールを使用することで、web.configにロールを指定したページのアクセス件の設定もできるようになります。ただ動的にアクセス権を変更できる今回の要件には宣言的なアクセス権の設定は完全には適合しません。

 

推測ですが、ブロンコさんの方法はASP.NET1.1などから続けて行っている認証方法ではないですか？間違っていたら申し訳ありません。その方法もASP.NET 2.0で引き続き使用できます。ただASP.NET2.0では開発者の負担を軽減するためにプロバイダモデルや認証用のコントロールが導入され、プロバイダモデルを使用するとASP.NET2.0で提供される機能の恩恵を受けやすくなるということだと思います。

(結局、設計する人がプロバイダモデルを含めASP.NETやWebアプリケーションの全く理解していなければ、用意されている機能を活かした開発はできませんけど。)

 

冒頭でも述べましたが、動的にアクセス権のページが変わる要件で正解というのは断言できませんが、プログラム上でコードをかいてチェックが簡単だと思います。

それにちゃんと動いているのなら無理して新しく提供されたものにあわせる必要はないような気もします。

 

なんかあんままとまっていませんね。申し訳ありません。

 

#AuthorizationModuleを作るという方法もありますね。完全に頭から抜けていました。勉強になります。

Answer 13

認証やロールの管理と、承認処理は独立しています。

例えばWeb.configのauthorizationに記述している場合は、UrlAuthorizationModuleクラスが現在のロールでのチェックを実行します。

 

ですので標準的なやり方を踏襲するなら、DBから情報を読んでくるカスタムの～AuthorizationModuleを自作してHTTPモジュールとして登録するか、

もっと簡単にAuthorizeRequestイベント辺りで処理を書いてもいいです。

 

ロールに対する判定の実装が変わるからといって、認証やロール管理そのものを自作したり、あるいは専用にやり方を変える必要はありません。

※これらは独立しているからです。

 

あと、Web.configの書き換えはやめた方がいいです（普通やっては駄目です）。

※<authorization>要素を無理やり別ファイルに外だしすればやれないこともないかもしれませんが

 

Answer 14

ブロンコ さんからの引用

で、こういう認証と承認の要件では、この実装方法というかシステム設計は正しい方法なのでしょうか？ なにが正しいってないとは思うのですが、一般的な方法はあるのでしょうか？   こういった要件を要求されて、構築された方がおられたら、アドバイスください。

 

Web Surfing をしていたら、以下のようなページを見つけましたのでご参考に連絡
します。

 

http://www.atmarkit.co.jp/fdotnet/dotnettips/177asppgusracs/asppgusracs.html
ページ単位にユーザーのアクセス可否を制御するには？

 

上記は、なちゃさんのレスにあった、「DBから情報を読んで」「AuthorizeRequest
イベント辺りで処理」する方法に近いものと思います。

 

これが標準とか、正しいという訳ではないと思いますが、自分がやるとしたら、認
証と承認はできる限り ASP.NET 標準のものを実装して、各ページへのアクセス制限
のみ上記 Web ページを参考に実装すると思います。

 

FormsAuthenticationTicket を作って、それをセッション Cookie に入れて・・・と
いった操作をするより、はるかに簡単で確実そうですし。

Answer 15

皆さん、こんにちは。

たくさんのアドバイスありがとうございます。

 

皆さんの意見を踏まえまして、認証は.net標準の方法を採用して、承認は自作してみようと思います。

承認のタイミングは、マスタページまたは、AuthorizeRequestで都合のいい方にしてみようと思います。

 

認証していれば、DBからユーザー情報（承認されたURLなど）を取得して、セッションに格納します。どうも認証と承認を合わせて行おうとしていたので、歪みが生じたのでしょう。

 

なちゃ さんからの引用

ですので標準的なやり方を踏襲するなら、DBから情報を読んでくるカスタムの～AuthorizationModuleを自作してHTTPモジュールとして登録するか、 もっと簡単にAuthorizeRequestイベント辺りで処理を書いてもいいです。

 

ちと、私には荷が重そう＾＾；なので、AuthorizeRequestで検討してみます。

 

なちゃ さんからの引用

推測ですが、ブロンコさんの方法はASP.NET1.1などから続けて行っている認証方法ではないですか？間違っていたら申し訳ありません。その方法もASP.NET 2.0で引き続き使用できます。ただASP.NET2.0では開発者の負担を軽減するためにプロバイダモデルや認証用のコントロールが導入され、プロバイダモデルを使用するとASP.NET2.0で提供される機能の恩恵を受けやすくなるということだと思います。 (結局、設計する人がプロバイダモデルを含めASP.NETやWebアプリケーションの全く理解していなければ、用意されている機能を活かした開発はできませんけど。)

 

このやり方は、以前一緒に仕事をした方が、この認証方法を実装しておりましたので、再利用させてもらいました。

私はまだ、.netは経験一年と少しだけで、ASP.NET1.1は触ったことがないです。