Принятый ответ ( https://stackoverflow.com/a/41348219/4974715 ) не является реально поддерживаемым или подходящим, поскольку в качестве утверждения используется «CanReadResource» (но, по сути, это должна быть политика в действительности, IMO). Подход к ответу не подходит в том смысле, в котором он использовался, потому что если метод действия требует много разных настроек утверждений, то с этим ответом вам придется многократно писать что-то вроде ...
[ClaimRequirement(MyClaimTypes.Permission, "CanReadResource")]
[ClaimRequirement(MyClaimTypes.AnotherPermision, "AnotherClaimVaue")]
//and etc. on a single action.
Итак, представьте, сколько потребуется кодирования. В идеале «CanReadResource» должен быть политикой, которая использует много утверждений, чтобы определить, может ли пользователь прочитать ресурс.
Что я делаю, я создаю свою политику как перечисление, а затем перебираю и устанавливаю требования следующим образом ...
services.AddAuthorization(authorizationOptions =>
{
foreach (var policyString in Enum.GetNames(typeof(Enumerations.Security.Policy)))
{
authorizationOptions.AddPolicy(
policyString,
authorizationPolicyBuilder => authorizationPolicyBuilder.Requirements.Add(new DefaultAuthorizationRequirement((Enumerations.Security.Policy)Enum.Parse(typeof(Enumerations.Security.Policy), policyWrtString), DateTime.UtcNow)));
/* Note that thisn does not stop you from
configuring policies directly against a username, claims, roles, etc. You can do the usual.
*/
}
});
Класс DefaultAuthorizationRequirement выглядит так ...
public class DefaultAuthorizationRequirement : IAuthorizationRequirement
{
public Enumerations.Security.Policy Policy {get; set;} //This is a mere enumeration whose code is not shown.
public DateTime DateTimeOfSetup {get; set;} //Just in case you have to know when the app started up. And you may want to log out a user if their profile was modified after this date-time, etc.
}
public class DefaultAuthorizationHandler : AuthorizationHandler<DefaultAuthorizationRequirement>
{
private IAServiceToUse _aServiceToUse;
public DefaultAuthorizationHandler(
IAServiceToUse aServiceToUse
)
{
_aServiceToUse = aServiceToUse;
}
protected async override Task HandleRequirementAsync(AuthorizationHandlerContext context, DefaultAuthorizationRequirement requirement)
{
/*Here, you can quickly check a data source or Web API or etc.
to know the latest date-time of the user's profile modification...
*/
if (_aServiceToUse.GetDateTimeOfLatestUserProfileModication > requirement.DateTimeOfSetup)
{
context.Fail(); /*Because any modifications to user information,
e.g. if the user used another browser or if by Admin modification,
the claims of the user in this session cannot be guaranteed to be reliable.
*/
return;
}
bool shouldSucceed = false; //This should first be false, because context.Succeed(...) has to only be called if the requirement specifically succeeds.
bool shouldFail = false; /*This should first be false, because context.Fail()
doesn't have to be called if there's no security breach.
*/
// You can do anything.
await doAnythingAsync();
/*You can get the user's claims...
ALSO, note that if you have a way to priorly map users or users with certain claims
to particular policies, add those policies as claims of the user for the sake of ease.
BUT policies that require dynamic code (e.g. checking for age range) would have to be
coded in the switch-case below to determine stuff.
*/
var claims = context.User.Claims;
// You can, of course, get the policy that was hit...
var policy = requirement.Policy
//You can use a switch case to determine what policy to deal with here...
switch (policy)
{
case Enumerations.Security.Policy.CanReadResource:
/*Do stuff with the claims and change the
value of shouldSucceed and/or shouldFail.
*/
break;
case Enumerations.Security.Policy.AnotherPolicy:
/*Do stuff with the claims and change the
value of shouldSucceed and/or shouldFail.
*/
break;
// Other policies too.
default:
throw new NotImplementedException();
}
/* Note that the following conditions are
so because failure and success in a requirement handler
are not mutually exclusive. They demand certainty.
*/
if (shouldFail)
{
context.Fail(); /*Check the docs on this method to
see its implications.
*/
}
if (shouldSucceed)
{
context.Succeed(requirement);
}
}
}
Обратите внимание, что приведенный выше код может также включить предварительное сопоставление пользователя с политикой в вашем хранилище данных. Таким образом, при составлении заявок для пользователя вы в основном извлекаете политики, которые были предварительно сопоставлены с пользователем прямо или косвенно (например, потому что у пользователя есть определенное значение заявки, и это значение заявки было идентифицировано и сопоставлено с политикой, например, что он обеспечивает автоматическое сопоставление для пользователей, которые также имеют это значение утверждения), и включает политики в качестве утверждений, так что в обработчике авторизации вы можете просто проверить, содержат ли утверждения пользователя требование. Политика в качестве элемента значения утверждения в их претензии. Это для статического способа выполнения требования политики, например, требование «Имя» носит статический характер. Так,
[Authorize(Policy = nameof(Enumerations.Security.Policy.ViewRecord))]
Динамическое требование может касаться проверки возрастного диапазона и т. Д., А политики, в которых используются такие требования, не могут быть предварительно сопоставлены пользователям.
Пример проверки заявок на динамическую политику (например, чтобы проверить, не старше ли пользователя 18 лет) уже находится на ответе, заданном @blowdart ( https://stackoverflow.com/a/31465227/4974715 ).
PS: я набрал это на моем телефоне. Простите за любые опечатки и отсутствие форматирования.