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

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

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

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

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

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

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

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

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

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

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

• AddUsersToRoles
• RemoveUsersFromRoles

そして、ハードコーディングされるため、いくつかのものが実際にはもう意味をなさない

• DeleteRole
• CreateRole

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

クレームはリソースとアクティビティを説明します-ACLのエントリのようなものですが、「リソース」は物理的なオブジェクトである必要はないため、リソースは何でもかまいませんし、情報を含めることができます。あなたが欲しい。

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

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

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