0

次のシナリオがあります。

  • 複数のユーザー(<100)
  • ADのユーザーアカウント(さまざまなグループの下)
  • ADのすべてのグループは、内部部門に対応しています。各部門には少なくとも1人のスーパーバイザーがいます
  • (1つは言うかもしれません)私たちは相互監督を持っています(グループのグループに適用できる監督者の役割があります、すなわち、実際に3つまたはグループを監督する1人の監督者がいる可能性があります-ADに存在します)
  • 複数の内部システム。その半分はWebベースであり、すべてが.NetFramework上に構築されています。

現在、ほとんどのデスクトップベースのシステムは、フォルダーのアクセス許可によってユーザーを認証しています(ClickOnceを使用してネットワーク環境に展開され、各展開フォルダーは個々のユーザーによって許可されます)。ただし、これはすべてのデスクトップシステムで機能するわけではありません。次のように、2つは独自の組み込み認証システムを使用しています。

  • システムAは、基本的にさまざまなデータテーブルで構成されています(画面に一部のデータを表示するだけです)。

  • すべてのデータテーブルは、実際には同じデータの異なるグループです。このデータは特定のアカウントを参照しています。

  • すべてのアカウント行には、列{number、owner、type、data1、data2、data3、data4...}が含まれています。さまざまなグループ化は、番号/所有者/タイプに基づいています。

  • すべてのdata(n)列は数値です(グループ化が完了すると、各グループ化の合計が表示されます)

この特定のシステムでは、データ列はグループに帰属します。したがって、AD Group1のユーザーは列データ(1-5)を表示でき、Group2は列データ(7-9)を表示できます。ただし、各グループのスーパーバイザーは、グループの追加の列を1つ見ることができます(Group1のスーパーバイザーはdata(1-5)とdata6-を見ることができます。これをグループの「特別な列」と呼びます)。他のグループの列(「特別な列」を含むかどうかに関係なく)を表示できるスーパーバイザー、すべての列を表示できる一般的なスーパーバイザー、およびすべての非特殊な列を表示できるユーザーもいます。それは混乱です。

この問題を解決するには、ClickOnceだけでは不十分です。つまり、基本的に開発チームが行ったのは、特定の承認アセンブリを埋め込むことでした。これは、現在のシステムをパラメーターとして使用してデータベースにクエリを実行し(他のシステムをサポートします)、結果として列名のセットを返します。これらの結果は、特定のユーザー列のみを取得する別のクエリで使用されます。

このレガシーシステムは、新しいシステムに置き換えられようとしています。多くの検討(保守性を含む-システムアーキテクチャは混乱しています)の後、最小限の処理でデータを取得して表示するだけなので、クエリ(の一部)を使用してデータ取得ロジックを書き直すことにしました。

その上、既存のWebベースのシステムのほとんどはハードコードで許可されています(if(sADLogin == "userA"){..}); それらのいくつかは、特定のユーザーに送信され、指を交差させた非常に直感的でないURLのみに依存しています。悲しい。

許可にはより抽象的なアプローチを使用したいと思います(すべてのシステムで同じ認証プロバイダーを使用できるようにするため)。Webサービス/WCFを使用するのが適切だと思われます(デスクトップベースのシステムと一部のスプレッドシートを認証する必要があることも考慮すると、おそらくモニカを使用します)。しかし、それに適したパターンやアーキテクチャモデルを見つけることができませんでした。Microsoftのドキュメントには、Windowsグループを役割として使用できないことを除いて、そのほとんどを解決する1つのWCFイントラネットパターンがあります。インターネットパターン(http://msdn.microsoft.com/en-us/library/ff650091.aspx)がありますが、それは役割の問題を処理しているようです(これは私が今行っていることです)が、 WCFセキュリティを扱うのは初めてです。

何か案は?

ありがとう、

4

1 に答える 1

0

Web ベースのアプリケーションの場合、これは組み込みの ASP.NET プロバイダー モデルを使用して Active Directory にシングル サインオンすることで簡単に解決できます ( http://msdn.microsoft.com/en-us/library/aa478948.aspxを参照)。 )。認証には Active Directory を使用し、承認にはドメイン グループを使用できます。ページへのアクセス (web.config のタグを使用)、ページの特定の部分へのアクセス ( を使用)、およびコードへのアクセス (User.IsInRole() または RolePermission 属性を使用) を制限する組み込みの方法がいくつかあります。すべてが自動的に機能します。Web の場合、これは一種の標準です (インターネットまたはイントラネット)。

非 Web ベースのアプリケーションの場合、実際には同じプロバイダー モデルの機能を引き続き使用できます。また、Active Directory でグループ メンバーシップを簡単に検索することもできます。

誰かがどのグループに属しているかを知ることだけが必要な場合は、おそらくこれがその方法です。代わりに、そのデータベース テーブルにもっと複雑なもの (委任承認など) がある場合は、その前に WCF サービスをスローし、すべてのアプリケーションでそれを使用することができます。ただし、ASP.NET の場合は、引き続きプロバイダー モデルを使用し、独自の RoleProvider を作成するだけで、ASP.NET セキュリティのすべての組み込み機能を引き続き使用できます。それが役立つことを願っています。

于 2010-06-27T23:03:50.297 に答える