web-dev-qa-db-ja.com

ASP.NET Identityのロールとクレームのベストプラクティス

ASP.NETIdentityでclaimsを使用するのはまったく新しいので、Roles and/or Claimsの使用におけるベストプラクティスのアイデアを取得したいです。

このすべての読書の後、私はまだのような質問があります...

Q：ロールを使用しなくなりましたか？
Q：その場合、なぜロールがまだ提供されていますか？
Q：クレームのみを使用する必要がありますか？
Q：ロールとクレームを一緒に使用する必要がありますか？

私の最初の考えは、それらを一緒に「使用すべき」だということです。 Claimsは、サポートするRolesのサブカテゴリとして表示されます。

例：
役割：会計
クレーム：CanUpdateLedger、CanOnlyReadLedger、CanDeleteFromLedger

Q：それらは相互に排他的であることを意図していますか？
Q：または、申し立てのみを行って、申し立てを「完全に認定」する方が良いでしょうか？
Q：それでは、ここでのベストプラクティスは何ですか？

例：役割とクレームを一緒に使用する
もちろん、このために独自の属性ロジックを記述する必要があります...

[Authorize(Roles="Accounting")]
[ClaimAuthorize(Permission="CanUpdateLedger")]
public ActionResult CreateAsset(Asset entity)
{
    // Do stuff here

    return View();
}

例：申し立ての完全修飾

[ClaimAuthorize(Permission="Accounting.Ledger.CanUpdate")]
public ActionResult CreateAsset(Asset entity)
{
    // Do stuff here

    return View();
}
asp.net-mvcrolesclaims-based-identity
83
Prisoner ZERO

ロールは、同じレベルのセキュリティ特権を共有するユーザーを収集する象徴的なカテゴリです。役割ベースの承認では、最初にユーザーを識別し、次にユーザーが割り当てられている役割を確認し、最後にそれらの役割をリソースへのアクセスが許可されている役割と比較する必要があります。

対照的に、クレームはユーザーが自分自身を識別する権利です。言い換えれば、「私はこの主張を持っているので、これを行うことが許されている」。一般に、クレームベースの承認はロールベースの承認を含みます。正確には、ロールメンバシップはIDに基づいて決定され、IDはクレームの価値に対する一種の権利にすぎません。役割は本質的に非常に特殊な種類の要求です。つまり、「ユーザー名がこれであるため、私はこの役割のメンバーです。この役割のメンバーであるため、このリソースにアクセスできます。」.

can両方を同時に使用するか、特定の状況で1つのタイプを使用し、他の状況で他のタイプを使用します。それは主に、他のシステムとの相互運用と管理戦略に依存します。たとえば、特定のクレームが割り当てられているユーザーを管理するよりも、マネージャーがロールに割り当てられたユーザーのリストを管理する方が簡単な場合があります。クレームは、クライアントにクレームを割り当てることができるRESTfulシナリオで非常に役立ち、クライアントはリクエストごとにユーザー名とパスワードを渡すのではなく、承認のためにクレームを提示できます。

71
Claies

@Claiesが完全に説明したように、クレームはより記述的であり、深い種類の役割です。私はそれらをあなたの役割のIDとして考えています。私はジムIDを持っているので、メンバーロールに属します。私はキックボクシングレッスンにも参加しているので、彼らに対する主張があります。キックボクシングID。私の申請には、私の会員権に適合する新しい役割の宣言が必要です。代わりに、ジムでできる特別なことごとにIDを持っています。多くの新しい会員タイプの代わりに。それが、クレームが私にとってより適している理由です。

Barry Dorransの素晴らしい説明ビデオがあり、役割よりもクレームを使用することの利点について説明しています。また、下位互換性のために、ロールは.NETに残っていると述べています。このビデオは、クレーム、役割、ポリシー、認可、認証の仕組みについて非常に有益です。

こちらにあります： ASP.NET Bar Authorization with Barr Dorrans

23
Jonathan Ramos

何十年にもわたってさまざまな認証および承認の手法を使用してきた私の現在のMVCアプリケーションは、次の方法論を使用しています。

クレームはすべての承認に使用されます。ユーザーには1つのロールが割り当てられます（複数のロールが可能ですが、これは必要ありません）-以下で詳しく説明します。

一般的な方法として、ClaimsAuthorize属性クラスが使用されます。ほとんどのコントローラーアクションはCRUDであるため、すべてのコントローラーアクションを繰り返し、読み取り/編集/作成/削除の各コントローラーアクション属性のクレームタイプを作成するルーチンをコードファーストデータベースに生成します。例えば。から、

[ClaimsAuthorize("SomeController", "Edit")]
[HttpPost]

MVCビューで使用するために、ベースコントローラークラスはビューバッグアイテムを提示します

        protected override void OnActionExecuting(ActionExecutingContext filterContext)
        {
            // get user claims
            var user = filterContext.HttpContext.User as System.Security.Claims.ClaimsPrincipal;

            if (user != null)
            {
                // Get all user claims on this controller. In this controler base class, [this] still gets the descendant instance type, hence name
                List<Claim> claims = user.Claims.Where(c => c.Type == this.GetType().Name).ToList();

                // set Viewbag with default authorisations on this controller
                ViewBag.ClaimRead = claims.Any(c => c.Value == "Read");
                ViewBag.ClaimEdit = claims.Any(c => c.Value == "Edit");
                ViewBag.ClaimCreate = claims.Any(c => c.Value == "Create");
                ViewBag.ClaimDelete = claims.Any(c => c.Value == "Delete");
            }

            base.OnActionExecuting(filterContext);
        }

Webサイトのメニューやその他のコントローラー以外のアクションについては、別の主張があります。例えば。ユーザーが特定の通貨フィールドを表示できるかどうか。

bool UserHasSpecificClaim(string claimType, string claimValue)
{
    // get user claims
    var user = this.HttpContext.User as System.Security.Claims.ClaimsPrincipal;

    if (user != null)
    {
        // Get the specific claim if any
        return user.Claims.Any(c => c.Type == claimType && c.Value == claimValue);
    }

    return false;
}

public bool UserHasTradePricesReadClaim
{
    get
    {
        return UserHasSpecificClaim("TradePrices", "Read");
    }
}

では、ロールはどこに収まるのでしょうか？

ロールをクレームの（既定の）セットにリンクするテーブルがあります。ユーザーの承認を設定する場合、デフォルトでは、ユーザーに自分の役割の主張が与えられます。各ユーザーは、デフォルトよりも多いまたは少ないクレームを持つことができます。編集を簡単にするために、クレームリストはコントローラーとアクション（行）で表示され、他のクレームがリストされます。ボタンは、クレームを選択するために必要な「クリック」を最小限に抑えるために一連のアクションを選択するために、少しのJavaScriptとともに使用されます。保存時に、ユーザーの申し立てが削除され、選択したすべての申し立てが追加されます。 Webアプリケーションはクレームを1回だけロードするため、すべての変更はこの静的データ内でリロードを促す必要があります。

そのため、マネージャーは、各クレームに含まれるクレームと、ユーザーがロールとデフォルトのクレームに設定した後にユーザーが持つクレームを選択できます。システムには少数のユーザーしかいないため、このデータの管理は簡単です。

6
pixelda

ロールとクレームの違いを理解し、ロールの制限に直面し、クレームがこの問題をどのように解決するかを感じるために、ロールがこの問題を解決できないクレームの力を認識する2つのシナリオを示します。

1-サイトには2つのモジュール（ページ、サービスなど）があり、最初のモジュールは子供（18歳未満）、もう1つは大人（18歳以上）で、ユーザーIDには誕生日のクレームがあります

各モジュールの承認がこの値で与えられ、ユーザーの年齢が18歳を超えた場合、この年齢の前ではなく成人のモジュールに進むことができるように、このクレームに関するポリシーを作成する必要があります

ロールは、ロールのロールにモルティ値を持たせることも持たないこともできるブールデータ型です。

2-サイトにロールユーザーがあり、コードを変更せずにメンテナンスを行うためにユーザーのアクセスを防止したくない

クレームでは、UnderConstrainポリシーを作成して、真のユーザーがページを表示できない場合、ロールユーザーのプロパティに権限を付与できます。

1
mohammed rashed