ページとボタンのアクセスをきめ細かく制御するための、顧客が構成可能な ASP.NET Web サイトのセキュリティ

StackOverflow https://stackoverflow.com/questions/176338

質問

ASP.NET 2.0 [ajax はまだありません] Web サイトがあり、コンパイルされた形式で複数の顧客サイトに展開されます。通常、サイトはイントラネットのみになります。顧客の中には、すべての従業員を信頼し、サイトやページの機能へのアクセス制限を気にしない人もいます。また、誰も信頼せず、特定の人やグループのみが特定のページを閲覧したり、特定のボタンをクリックしたりできるようにしたいと考えている顧客もいます。アル。

独自のソリューションを実行して、データベーステーブルからアクセス許可を制御することもできますが、その道に進む前に、SOで質​​問しようと思いました。この状況に対する良い解決策は何ですか?Web サイトの再構築は (クライアントにとっては不可能であり、クライアントのために何度も行う必要はありません) できないため、web.config ファイルおよび/またはデータベースで完全に制御できるものが望ましいです。Active Directory の統合はボーナスではありますが、要件ではありません (それがより簡単な場合を除く)。

出発点として、サイト内の各ページ/機能ポイントに ID を与え、権限グループに関連付けることを考えています...

編集：web.config の承認セクションでロールおよびユーザーごとにアクセスを許可/拒否するのは良いことですが、それは問題の半分にすぎません。残りの半分は、各ページの個々のメソッド (ボタンなど) へのアクセスを制御することです。たとえば、一部のユーザーは whatchamacallits を表示でき、他のユーザーは編集、作成、削除、または無効化/有効化を許可されます。これらのボタン、リンク、アクションはすべてビュー ページにあります。

[理想的には無効化されたボタンを非表示にしますが、ここではそれは重要ではありません]

編集：これまでのところ、いくつかの良い提案がありますが、完全な解決策はまだありません。データベース主導のソリューションに傾いています...

  • セキュリティ権限要求属性は、ボタンがクリックされると例外をスローしますが、これは友好的な行為ではありません。ユーザーが使用できないボタンは非表示にしたいのですが
  • LoginView コントロールも興味深いものですが、ページ コンテンツのほとんどを数回 (ロールごとに 1 回) 複製する必要があり、ユーザーが複数のロールに属している場合は処理できない可能性があります。ロールが階層的であるとは想定できません。顧客によって定義されます

編集：プラットフォームは Win2K/XP、SQL Server 2005、ASP.NET 2.0、AJAX は使用していません

役に立ちましたか？

解決

特定のユーザーではなく、ADグループにアクセス権を付与することを好みます。はるかに柔軟だと思います。

アプリケーションについてはあまり知りませんが、web.configファイル内の認証タグを確認することをお勧めします。

<authorization>
    <!--  
        <deny users="?" />
        <allow     users="[comma separated list of users]"
                   roles="[comma separated list of roles]"/>
        <deny      users="[comma separated list of users]"
                   roles="[comma separated list of roles]"/>
    -->
</authorization>

web.configファイルをWebアプリケーション内の各ディレクトリに分離し、ディレクトリをネストできます。各web.configファイルには、独自の承認セクションを含めることができます。各ディレクトリに異なるページを配置すると、各web.configで特定のロールを許可し、他のすべてを拒否することにより、セキュリティを効果的に厳密に管理できます。その後、Active Directoryで各ロールのメンバーを管理できます。これは、MicrosoftのActive DirectoryとASP.NETセキュリティフレームワークを使用して独自のカスタムスタッフを作成することなく、効果的なソリューションであることがわかりました。 AD管理コンソールの使用方法を知るために必要なweb.configファイルに触れる必要はありません。

他のヒント

ここで行う必要があるのは、ビジネスオブジェクトまたはコントローラーのいずれかにアクセス許可クエリメソッドのセットを実装することだと思います。例：CanRead（）、CanEdit（）、CanDelete（）

ページをレンダリングするとき、ビジネスオブジェクトを照会し、ユーザーに許可された機能を決定し、この情報に基づいて機能を有効または無効にする必要があります。ビジネスオブジェクトは、ロールまたは追加のデータベースクエリを使用して、アクティブなユーザーのアクセス許可を決定できます。

これらの権限を宣言的に一元的に定義する方法は考えられません。関数の実装に配布する必要があります。ただし、設計を改善したい場合は、依存性注入を使用して承認者をビジネスオブジェクトに挿入し、実装を分離しておくことができます。

Rocky Lhotkaの本には、このモデルを使用するコードがいくつかあります。新しいバージョンは、 Google はまだです。

実際にこれを実際に使用したことはなく、そのメリットを主張することはできませんが、.NETにはロールベースのコードセキュリティがあり、ロールまたはユーザーごとにメソッドを宣言的にロックダウンできます。例：

[PrincipalPermissionAttribute(SecurityAction.Demand, Name = "MyUser", Role = "User")]
public static void PrivateInfo()
{   
    //Print secret data.
    Console.WriteLine("\n\nYou have access to the private data!");
}

ロールベースのセキュリティについては、こちらで詳しく説明しています。それを変更するには再コンパイルが必要になると考えられますが、私はそれがあなたに大いに役立つことを知りません。ただし、メソッドにラベルを付けると、ボタンを表示/非表示にしたり、コードでセキュリティ検証を行うロジックを構築するよりも高速です。

さらに、Integratedで参照することもできます。 Active Directoryの可能性を得るためのWindows認証。

を使用できるようです ログインビュー コントロール。特定のユーザーまたはロールのみにコントロールのパネルを表示できます。ロールは最も柔軟です。セキュリティが必要ない場合は、すべてのユーザーをすべてのロールに割り当てます。

標準の web.config セキュリティ (アクティブ ディレクトリを備えた統合 Windows、またはフォーム認証 (asp 2 SQL サーバー スキーマまたは独自のもの) と組み合わせて使用​​します。

<asp:LoginView id="LoginView1" runat="server">
                    <RoleGroups>
                        <asp:RoleGroup Roles="Admin">
                            <ContentTemplate>
                                <asp:LoginName id="LoginName2" runat="Server"></asp:LoginName>, you
                                are logged in as an administrator.
                            </ContentTemplate>
                        </asp:RoleGroup>
                        <asp:RoleGroup Roles="User">
                            <ContentTemplate>
                                <asp:Button id="Button1" runat="Server" OnClick="AllUserClick">
                            </ContentTemplate>
                        </asp:RoleGroup>
                    </RoleGroups>
                </asp:LoginView>

私は、必要なきめ細かい制御を得るために、AD認可をデータベースの「機能と権限」テーブルと組み合わせる必要があると思います-

  • web.configファイルを使用して、許可されたユーザー（ADグループ経由）のみがWebサイトにアクセスできるようにします
  • 影響を受ける可能性のある各ページと機能をリストする「機能」テーブルを作成します。 1ページ目の編集ボタン、2ページ目の削除ボタン、3ページ目の詳細グリッドなど
  • 機能とその機能の使用が許可されているADグループを指定する「許可」テーブルを作成します
  • 禁止された機能を適切に無効化/非表示にするには、サイトのページを変更してページ読み込みの機能許可を確認します（または必要に応じて事前にレンダリングします）

例：

  • 管理者はサイトのすべての機能を使用できます
  • 開発者はサイトのすべての機能を使用できます
  • マネージャーはすべてのページを表示できますが、情報の追加と編集のみが可能で、削除はできません
  • スーパーバイザーはすべての部門の概要を表示できますが、自分の部門の詳細のみを表示および編集できます（各部門とdept-supervisorのADグループがあります）
  • スタッフは部門の詳細のみを表示できます
  • など

最終的な解決策では、「機能」の概念をバイナリの使用可能または使用不可の決定に減らし、各機能に「許可/非許可」フラグを追加しました。これにより、ほとんどの人が使用できる機能を「許容」として定義でき、権限テーブルはその機能を使用する権限を拒否されたグループのみを記録する必要があります。非許容として定義された機能の場合、デフォルトでは誰もその機能を使用できず、その機能の使用を許可されているグループの許可テーブルエントリを作成する必要があります。これは、各機能に必要な許可レコードの数を削減するという点で、世界最高のソリューションを提供するようです。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top