問題タブ [roles]

私は ASP.NET のバックグラウンドを持っており、控えめに言ってもロール ベースの承認スキーム全体が制限されていることがわかります。Microsoft の新しい ID モデルと、クレーム ベースのアーキテクチャを備えた Geneva Framework について読んだことがありますが、複雑すぎるようです。

一般的に、自分のニーズに最適なものを見つけるために、可能な承認アーキテクチャについてもっと知りたいと思っています。

たとえば、「管理者」のようなアプリケーション全体のロールを作成したい場合は、アプリケーション全体のロールで十分なようです。しかし、私がieを持っているとしたらどうでしょう。すべてのプロジェクトが独自のロール セット (たとえば、プロジェクト A では「編集者」、プロジェクト B では「写真家」) と関連する権限を持つプロジェクト エンティティを備えたプロジェクト管理アプリケーション。

このテーマでお勧めの本はありますか?

ここでこのVB.NETサンプルを変換しようとしました http://www.theproblemsolver.nl/usingthemembershipproviderinwinforms.htm

成功せずに、誰かが例を知っていますか?

ありがとう

サーバー ファームのジョブを管理および構成するために、ほぼすべての従業員が使用する Struts 2 Web アプリケーションがあります。お客様が自分のジョブを確認し、そのステータス (「処理中」、「校正準備完了」、「終了」など) を非常に簡単に表示できるように、お客様用のダッシュボードを作成する計画に取り組んでいます。顧客が見ることができるすべてのページは、従業員のビューよりもはるかに情報が少なく、何かを編集または変更する方法はありません. しかし、最終的には、それらは本質的に同じ情報に対する 2 つの別個のビューであり、1 つは非常に単純で、もう 1 つはより複雑で制御可能です。

これを行う単純な方法は、すべての単一の jsp に if/else を含めることです。

これを行う簡単な方法はありますか？"customer" という名前と "employee" (または default など) という名前の jsps の 2 つの別個のディレクトリを作成し、アクションでプロパティの Struts キーをオフにして、チェックするディレクトリを決定することはできますか?

または、これを行う別の方法はありますか？

実際には非常に単純な質問:

現在、IIS の匿名アクセスを無効にしています。ユーザーは Windows ログインを使用して自動的にログオンしています。ただし、User.IsInRole("Role name") を呼び出すと false が返されます。User.Identity.Name() と「ロール名」を再確認したところ、true が返されるはずです。

私は現在これを私の Web.Config に持っています:

更新
User.IsInRole("Role name") を呼び出していましたが、ここで User.IsInRole("DOMAIN\Role name") を呼び出す必要があります

ただし、 <membership> エントリが必要かどうかを知りたいですか?

何を変更すればよいですか？(そして <membership> エントリは必要ですか? )

私の本によると、ロール管理が有効になっている場合、オブジェクトを にRoleManagerModule割り当てることにより、ユーザーのセキュリティ コンテキストを作成します。しかし、呼び出される前に呼び出される によって、セキュリティ コンテキストが既に作成されている (つまり、プリンシパル オブジェクトが に割り当てられている)ではありませんか?RolePrincipalHttpRequest.UserHttpContext.UserFormsAuthenticationModuleRoleManagerModule

次のコードでは、まだ呼び出されていないHttpRequest.Userにもかかわらず、に割り当てられたプリンシパル オブジェクトが既に存在するため、私はこれを求めています。RoleManagerModule

FormsAuthenticationModuleによって作成され割り当てられたプリンシパル オブジェクトは、後でオブジェクト (によって作成された)HttpRequest.Userに置き換えられますか?RolePrincipalRoleManagerModule

C＃ドメイン駆動設計プロジェクトに役割とセキュリティをどのように実装しますか？呼び出し元のアプリケーション（ASP.NET MVC）で実装するのか、ドメインモデル自体（モデルエンティティとサービス）で実装するのかについては、議論の余地があります。認証がすでに存在するWebサイト自体にあるべきであると主張する人もいます。ただし、これは、コアビジネスシステムと統合するたびにセキュリティを再実装する必要があることを意味します。

例：管理者は、レコードの編集や削除など、システム内のほとんどすべてのアクションを実行できる必要があります（つまり、ユーザーの注文を削除できます）。一方、ユーザーは自分のレコードのみを編集および削除できる必要があります（つまり、ショッピングカートからアイテムを追加/削除できます）。

ちなみに、DDDとセキュリティに関する7つの異なるシナリオをカバーするトピックに関する素晴らしい論文があります。

ドメイン駆動設計におけるセキュリティ

• 第4章セキュリティサービスの設計シナリオ
  • 4.1シナリオ1：通常のサービスとしてのセキュリティサービス
  • 4.2シナリオ2：UIに組み込まれたセキュリティ
  • 4.3シナリオ3：ドメインモデルをカプセル化するセキュリティサービス
  • 4.4シナリオ4：UIのゲートウェイとしてのセキュリティサービス
  • 4.5シナリオ5：UIのアダプターとしてのセキュリティサービス
  • 4.6シナリオ6：AOPとアダプターが統合されたセキュリティサービス
  • 4.7シナリオ7：AOPと統合されたセキュリティサービス

私は個人的にPostSharpを使用してAOPに傾倒しますが、これまであまり多くのことをしていなかったため、飛躍することを躊躇しています。