web-dev-qa-db-ja.com

.NETアプリケーションの権限/適切なモデル/パターン

柔軟かつ簡単に（そのようなものが存在する場合）実装すると同時に、可能であれば組み込みの手段を利用する必要がある

これまでのところ、MembershipProviderとRoleProvidersを実装しています。これはかっこいいですが、次にどこに行きますか？

「Priviledge」という用語を追加し、アプリケーション内にハードコードする必要があるように感じます。ユーザーは、特権を役割に追加し、役割をユーザーに割り当てるように役割を構成します。

それは良いモデルのように聞こえますか？ロールに追加することに加えて、ユーザーレベルで特権を追加することを検討する必要がありますか？セットアップ（混乱）と次のサポートに問題があると思います。

そうしないと、一部の特定のユーザーにはより少ない特権が必要になります-管理者は別のロールを作成する必要があります。

このようなシステムの特効薬はありますか？そして、なぜMicrosoftはメンバーシップとロールプロバイダーよりも先に進まなかったのですか？

別のアイデア：ロールを「特権」ホルダーのままにして、ハードコーディングします。次に、使用可能なすべてのマークアップ/属性などを使用して、アプリ内のこれらのロールをコード化できます。すべてMicrosoftです。

新しいエンティティ「グループ」を追加し、このような関係を作成します

  • ユーザー
  • ユーザーグループ
  • 団体
  • RoleGroups
  • 役割

この方法で、ロールをグループに収集し、それらのグループをユーザーに割り当てることができます。素晴らしいサウンドで、他のソフトウェアパターンと一致します。しかし、それではRoleProvider内に次のようなものを実際に実装することはできません。

  • AddUsersToRoles
  • RemoveUsersFromRoles

そして、いくつかはハードコーディングされるため、もはや意味がありません。

  • DeleteRole
  • CreateRole
design-patternssecurity
9
katit

ロールベースの認証が十分に細かくない場合は、 クレームベースの認証 の使用を検討してください。

クレームはリソースとアクティビティを説明します-ACLのエントリのようなものですが、「リソース」は物理的なオブジェクトである必要はないので、より柔軟にできます。あなたが欲しい。

このモデルでは、クレームは「特権」と呼ばれるものと同等であり、クレームをクレームセットにグループ化します。これは、「ロール」と呼ばれるものとほぼ同等です。これらすべてのAPIなどは、すでにSystem.IdentityModel名前空間にあります。

もちろん、あなたはMembershipProviderとRoleProviderについて言及し、これらすべてをASP.NETメンバーシップモデルに詰め込もうとする場合（これらの名前が示すように）、それについては忘れてください。これらのプロバイダーAPIを使用する場合は、独自の方法で行う必要があり、その方法はロールの概念よりも細かくなりません。

代わりに、ASP.NETでは、「特権」の概念は実際にはactionまたはoperationレベルでは、そのアクションの実行を許可されるロールを宣言します。これは、コントローラーまたはコントローラーアクションで[AuthorizeAttribute]をたたくだけのASP.NET MVCで処理するほうがはるかに簡単です。 「古い」ASP.NETでは、イベントを処理しているため、承認はアドホックかページレベル（またはその両方）のいずれかになります。

5
Aaronaught