3

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

自家製のソリューションを実行して、データベーステーブルからアクセス許可を取得することもできますが、その道を進む前に、SOで質​​問すると思いました。この状況に適したソリューションは何ですか。Webサイトを再構築することはできないため、web.configファイルやデータベースで完全に制御できるものが望ましいです（クライアントにとっては、何度も何度も行う必要はありません）。Active Directoryの統合はボーナスですが、必須ではありません（それが簡単でない限り）。

出発点として、サイト内の各ページ/ファンクションポイントにIDが与えられ、アクセス許可グループに関連付けられていると思います...

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

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

編集：これまでのところいくつかの良い提案がありますが、完全な解決策はまだありません-まだデータベース駆動型の解決策に傾いています...

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

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

4

5 に答える 5

2

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

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

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

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

于 2008-12-19T21:19:08.353 に答える
1

特定のユーザーではなく、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アプリケーション内のディレクトリごとにweb.configファイルを分離したり、ディレクトリをネストしたりできます。各web.configファイルには、独自の認証セクションを含めることができます。各ディレクトリに異なるページを配置すると、各web.configで特定の役割を許可し、他のすべてを拒否することで、セキュリティを効果的に厳密に管理できます。次に、ActiveDirectory内の各役割のメンバーを管理できます。これは、MicrosoftのActive DirectoryとASP.NETセキュリティフレームワークを独自のカスタムのものを作成せずにうまく利用し、ロールを使用する場合は、ロールメンバーシップの管理を誰かにオフロードできるため、効果的なソリューションであることがわかりました。 web.configファイルに触れる必要はなく、AD管理コンソールの使用方法を知っている必要があります。

于 2008-10-06T22:00:46.943 に答える
1

これまで実際にこれを使用したことがなく、そのメリットについて議論することはできませんが、.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!");
}

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

さらに、 Active Directory の可能性を得るために、統合 Windows 認証を読みたいと思うでしょう。

于 2008-10-07T05:59:47.583 に答える
1

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

標準の web.config セキュリティ (Active Directory と統合されたウィンドウ、またはフォーム認証 (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>
于 2008-10-07T06:09:44.443 に答える
0

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

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

例:

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

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

于 2008-10-17T05:51:49.330 に答える