.NetCoreでの権限制御の実現方法Claimロール、ポリシー、Claim機能ポイントによる処理
5318 ワード
.NetCoreで権限制御の問題が発生した場合、アクション操作にアクセスするときに権限制御を行う必要があります.
claimsロール制御に基づく
キャラクタベースのコントロールはなんだか範囲が大きすぎて、しかもコントロールしてもあまりよくない感じがします.例えば、アクションを追加して、キャラクタコントロールを通過すると、書くことで少し苦痛になります
1つの追加操作に20個のロールがアクセスできる場合は、ロールにすべてのロールを指定し、ユーザーのロールClaimsマッチングでアクセスする必要があります.
Claimsの
もちろん、インタフェースをカスタマイズして実装することもできますが、以下の機能点と同様に、キャラクタサービスによって判断を取得し、ここで処理する必要があるのはキャラクタ属性上のキャラクタ名を取得することです. ActionDescriptor 、 IAuthorizeData Roleの値を取得
ポリシー・ベースの制御
もちろん戦略処理も可能であり、戦略は大雑煮であり、以下に示す例のような異なる構成案を提供している.
上の方法はあまりよくありません.時には動的な構成機能ポイント権限が必要です.
たとえば、システムに役割を追加すると、その役割にもアクションを管理する権限があります.ここではaction上のRoleルールを設定する必要があります.役割ベースのClaim制御を使用するとよくありません.
ポリシー方式を採用する場合は、コードを修正する必要があります.また、システムに詳しい必要があります.その場所でポリシーやロールを使用してもだめです.そのため、次のClaims機能ポイント制御を採用します.
claims機能ポイント制御に基づく
ここではプロパティラベルを作成し、IAsyncAuthorizationFilterインタフェースを実装する必要があります.
機能点が多くなく、データ量が比較的小さい場合は、機能点情報をclaimsに直接追加したり、多すぎると動的に取得したり、動的にキャッシュを読み込んだりして効率を高めることができます.
実装コードを見てみましょう
次はActionに関連する機能点コードを指定すればいいです
Claimsの情報が多すぎる場合は、サービスのダイナミッククエリを取得して検証したり、キャッシュサービス(Redis、Cache)を取得したりすることで、StartupでDI上のサービスを利用することができます.
Claims情報の処理は、SignInにログインする際に関連するClaimsアイデンティティ情報を書き込めばよい.ここではClaimsIdentity(アイデンティティ情報)、ClaimsPrincipal(アイデンティティ、当事者、アイデンティティ所有者)について述べる
転載先:https://www.cnblogs.com/liyouming/p/9641453.html
claimsロール制御に基づく
キャラクタベースのコントロールはなんだか範囲が大きすぎて、しかもコントロールしてもあまりよくない感じがします.例えば、アクションを追加して、キャラクタコントロールを通過すると、書くことで少し苦痛になります
1つの追加操作に20個のロールがアクセスできる場合は、ロールにすべてのロールを指定し、ユーザーのロールClaimsマッチングでアクセスする必要があります.
Claimsの
claims.Add(new Claim(ClaimTypes.Role, "rolecode"));
[Authorize(Roles ="rolecode")]
もちろん、インタフェースをカスタマイズして実装することもできますが、以下の機能点と同様に、キャラクタサービスによって判断を取得し、ここで処理する必要があるのはキャラクタ属性上のキャラクタ名を取得することです. ActionDescriptor 、 IAuthorizeData Roleの値を取得
if (!context.HttpContext.User.IsInRole("rolename"))
{
context.Result = new ForbidResult();
}
ポリシー・ベースの制御
もちろん戦略処理も可能であり、戦略は大雑煮であり、以下に示す例のような異なる構成案を提供している.
[Authorize(Policy ="policyname")]
services.AddAuthorization(options => {
options.AddPolicy("policyname", policy => {
policy.RequireRole("rolename1", "rolename2");
policy.RequireClaim("claimname");
policy.RequireUserName("username");
} );
});
上の方法はあまりよくありません.時には動的な構成機能ポイント権限が必要です.
たとえば、システムに役割を追加すると、その役割にもアクションを管理する権限があります.ここではaction上のRoleルールを設定する必要があります.役割ベースのClaim制御を使用するとよくありません.
ポリシー方式を採用する場合は、コードを修正する必要があります.また、システムに詳しい必要があります.その場所でポリシーやロールを使用してもだめです.そのため、次のClaims機能ポイント制御を採用します.
claims機能ポイント制御に基づく
ここではプロパティラベルを作成し、IAsyncAuthorizationFilterインタフェースを実装する必要があります.
機能点が多くなく、データ量が比較的小さい場合は、機能点情報をclaimsに直接追加したり、多すぎると動的に取得したり、動的にキャッシュを読み込んだりして効率を高めることができます.
実装コードを見てみましょう
[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = true, Inherited = true)]
public class AuthorizeCodeAttribute : Attribute, IAsyncAuthorizationFilter
{
public AuthorizeCodeAttribute(string name)
{
Name = name;
}
public string Name { get; set; }
public async Task OnAuthorizationAsync(AuthorizationFilterContext context)
{
if (!context.HttpContext.User.HasClaim(c => c.Value == Name))
{
context.Result = new ForbidResult();
}
await Task.CompletedTask;
}
}
次はActionに関連する機能点コードを指定すればいいです
[AuthorizeCode(PermissionsConfig.ClassAdd)]
public IActionResult Create()
{
return View();
}
Claimsの情報が多すぎる場合は、サービスのダイナミッククエリを取得して検証したり、キャッシュサービス(Redis、Cache)を取得したりすることで、StartupでDI上のサービスを利用することができます.
var services= context.HttpContext.RequestServices.GetService();
Claims情報の処理は、SignInにログインする際に関連するClaimsアイデンティティ情報を書き込めばよい.ここではClaimsIdentity(アイデンティティ情報)、ClaimsPrincipal(アイデンティティ、当事者、アイデンティティ所有者)について述べる
転載先:https://www.cnblogs.com/liyouming/p/9641453.html