9

私は、Visual Studio 2011 ベータ版を使用して新しい asp.net mvc4 プロジェクトに取り組んでおり、セキュリティ全体について頭を悩ませようとしています。これは、最初にシングル サインオンを使用する内部イントラネット アプリケーションであるため、(まだ) ユーザーに Windows ID/パスワードの入力を求めるプロンプトは表示されません。この会社には、さまざまなアプリケーションのロールを格納するためのカスタム アプリケーションがあり、ストアド プロシージャ コールを介して利用できます。これは、ユーザーのログオン ID を受け取り、"MyApp.Data"、"MyApp.User、"MyApp.Admin" などのロールを含む何らかのコレクションを返します。つまり、これは何と呼ばれているのか - これはカスタム メンバーシップ プロバイダー、カスタム ロールですか?プロバイダか何か？

承認、認証、メンバーシップ、役割などのすべての詳細を調べてきましたが、現時点では木に木が見えません。既存の ASP.NET セキュリティ オブジェクトが試され、テストされていることを読みました。非常に複雑な要件がない限り、組み込みのもので十分なので、既にあるものを喜んで使用します。

ユーザーがすでにネットワークにサインインしている場合、これは認証されていることを意味します - 正しいですか? もしそうなら、Authorizationを実装するだけです。各コントローラーまたはアクションを Authorize 属性で装飾する必要はありますか? その場合、カスタム ロール ストレージ アプリからロールを取得すると、[Authorize(Roles = "ABC")] の "ABC" 部分はどのように設定されますか?

Jon Galloway の次の記事を含め、いくつかの記事やブログ記事を読みましたが、最後まで道に迷ってしまいました。

認証と承認を適切にカスタマイズする

非常に多くの質問...これらすべてがどのように結びついているかについての優れた高レベルの説明を誰かが知っているなら、私はすべて耳にします:)

4

3 に答える 3

8

これらすべてがどのように結びついているかについての高レベルのビューを提供する回答がない場合、これまでの調査結果を走り書きすると思いました。

  • 会社は Active Directory を使用してユーザー ログオンの詳細を保存します。これはメンバーシップに使用されるため、カスタム メンバーシップ プロバイダーは必要ありません。ユーザーが会社のネットワークにログオンすると、認証されます。グローバル Authorize フィルターを追加すると、システムにアクセスするすべてのユーザーを認証する必要があることが保証されます。msdn の Rick Anderson からの最新情報:

    http://blogs.msdn.com/b/rickandy/archive/2012/03/23/securing-your-asp-net-mvc-4-app-and-the-new-allowanonymous-attribute.aspx

したがって、Global.asax に次のように追加します。

public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
    filters.Add(new HandleErrorAttribute());
    filters.Add(new System.Web.Mvc.AuthorizeAttribute()); //new
}

  • ユーザーが認証されたら、承認を処理する必要があります。会社には既存のロール用のグローバル データ ストアがあり、更新アクセス権はなく、読み取りアクセス権しかないため、ストアド プロシージャ コールを介して特定のユーザーのロールを取得できます。リクエストが行われてからヘルプデスクがロールを作成するのに数日から数週間かかることがあります。このため、最初にユーザーと管理者の 2 つの標準ロールが作成され、その後のロールがアプリケーション データベースに保存されます。 .

  • これらの 2 つの標準的な役割に加えて、スーパーユーザーなどの後続の役割が必要です。これらの役割は、ビジネス ルールなどに応じてさまざまな権限を持ち、アプリケーション データベースに格納する必要があります。したがって、このシナリオでは、カスタム ロール プロバイダーを作成し、適切な asp.net ロール テーブルをアプリ データベースに追加して、それを web.config にプラグインする必要があります。これは、ロールを使用した承認の管理というタイトルのミリ秒ページで、一部を抜粋しています。

    http://msdn.microsoft.com/en-us/library/9ab2fxh0.aspx

  • これまでに読んだことから、カスタム ロール プロバイダーに必要なテーブルは Roles と UsersInRoles だけです。

    CREATE TABLE Roles ( Rolename Text (255) NOT NULL, ApplicationName Text (255) NOT NULL, CONSTRAINT PKRoles PRIMARY KEY (Rolename, ApplicationName) )

    CREATE TABLE UsersInRoles ( Username Text (255) NOT NULL, Rolename Text (255) NOT NULL, ApplicationName Text (255) NOT NULL, CONSTRAINT PKUsersInRoles PRIMARY KEY (Username, Rolename, ApplicationName) )

  • これがすべてセットアップされたら、グローバル データ ストアの 2 つの標準ロール (ユーザーと管理者) をアプリ データベースに格納されているカスタム ロールとマージする方法を理解する必要があります。 "Admin, Superuser")] コントローラー/アクションで、または AuthoriseAttribute をサブクラス化し、より巧妙なことを行う必要がある場合。

  • 認証にADを使用しているため、現在のユーザーがメンバーであるロールのコレクションを追加/注入する方法が必要であることに気付きました。したがって、カスタム メンバーシップ プロバイダーの機能は必要ありませんが、httpContext.User と対話して Roles コレクションを更新する必要があります。

于 2012-05-28T18:37:47.270 に答える
7

認証が既に Windows によって処理されている場合 (おそらく Active Directory 経由だと思います)、探しているのは、役割をユーザーに一致させる承認メカニズムです。1 つのオプションは、ユーザー ロールを現在のセッションに正常にロードすることです。次に、現在のセッションに必要なロールがあるかどうかを確認するカスタム承認属性を作成します。

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, Inherited=true, AllowMultiple=true)]
public class CustomAuthorizationAttribute : AuthorizeAttribute
{
   protected override bool AuthorizeCore(HttpContextBase httpContext)
   {         
      IPrincipal user = httpContext.User;
      if (!user.Identity.IsAuthenticated)
      {
          return false;
      }

     //check your users against a database and return true or false
      return base.AuthorizeCore(httpContext);
   }
}

次に、このような属性を使用できます

[CustomAuthorization]
public ActionResult SomeAction()
{
   return View();
}

アップデート

AuthorizeCore は、このユーザーがそれぞれのアクション メソッドへのアクセスを許可されているかどうかを確認するために使用されるメソッドです。このメソッド内で、httpContext.User.Identity.Name プロパティをデータベースまたはロールが保存されている場所と比較して確認できます。Active Directory 経由で Wi​​ndows 認証を使用している場合、HttpContext.User.Identity はWindowsIdentityのインスタンスである必要があります。

于 2012-05-25T02:22:55.353 に答える
1

RoleProvider と連携して更新される RolePrincipal だけで、認証されたユーザーに関連付けられたロールのリストを取得できます。RolePrincipal には適切な WindowsIdentity が既に含まれていることに注意してください。

カスタム Authorize 属性は必要ありません。RolePrincipal/RoleProvider は、必要なロールをフェッチし、標準の Authorize 属性を操作します。

少し奇妙に思えるのは、アプリケーションに固有の役割を持ちたいのに、別の企業ストアの Windows ユーザーに関連付けられた役割も必要だと言っていることです。あなたが言ったように、あなたはそれらをマージしたいと思っています。これは私には正しくないようです。アプリケーションのロールを企業レベルで管理するか、ローカル レベルで管理する必要があります。通常、両方を行うことはありません。

しかし、それが本当にやりたいことであれば、RoleProvider がサービス (WCF など) 呼び出しまたは AD 呼び出しを行って追加情報を取得する必要があるように思えます。おそらく、Windows ユーザーが属する「グループ」の名前が「ロール」として機能します。次に、アプリケーションが関心を持つグループのみを除外し、ローカル ロール データベースで見つけたロールと結合します。

すべての情報が収集されたら、ロール情報を Cookie に保存するよう roleManager に指示してください。ユーザーが要求するたびにその騒動を経験しても意味がありません。

于 2012-11-19T15:23:58.170 に答える