[解決済み] ASP.NET IdentityにおけるRolesとClaimのベストプラクティス

Q: これらは相互に排他的であることを意図しているのですか?

Q: それとも、Claims ONLY にして、"fully-qualify" する方が良いのでしょうか？

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();
}

どのように解決するのですか？

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

これに対して、クレームはグループベースではなく、むしろIDベースです。

から マイクロソフトのドキュメント :

ID が作成されると、信頼できる当事者によって発行された 1 つまたは複数の請求が割り当てられることがあります。クレームは名前と値のペアで、対象が何であるかを表し、対象が何ができるかを表すものではありません。

セキュリティチェックでは、1つ以上のクレームの値に基づいて、リソースにアクセスする権利を後で決定することができます。

あなたは は を同時に使用することもできますし、ある状況では 1 つのタイプを使用し、別の状況ではもう 1 つのタイプを使用することもできます。 これは主に、他のシステムとの相互運用や管理戦略に依存します。 例えば、管理者にとって、あるロールに割り当てられたユーザーのリストを管理することは、特定のクレームを割り当てられた人を管理することよりも簡単かもしれません。 クレームはRESTfulなシナリオで非常に有用です。クライアントにクレームを割り当てると、クライアントはリクエストごとにユーザ名とパスワードを渡す代わりに、クレームを提示して認証を受けることができるようになります。