2016-01-29 2 views
3

Я работаю над проверкой подлинности базы требований, и она работает нормально. Теперь я хочу добавить авторотацию роли. У меня есть роль претензии для пользователя (например, «Admin»)IsInRole возвращает false, даже если в претензиях есть роль

Когда метод IsInRole() вызывается, есть чек, чтобы увидеть, если текущий пользователь имеет эту роль. В приложениях, поддерживающих заявки, роль выражается типом заявки на роль, который должен быть доступен в токене . Тип роли требование выражается с помощью следующего URI: http://schemas.microsoft.com/ws/2008/06/identity/claims/role

//Include all claims 
//claims is List<Claim> with all claims 
var id = new ClaimsIdentity(claims, "Cookies"); 
Request.GetOwinContext().Authentication.SignIn(id); 

Если я проверить, если пользователь находится в роли я получить ложные. Хотя у меня есть Role иск «Администратор» значение

User.IsInRole("Admin"); 

также санкционировать attrubute на моем API не будет работать

[Authorize (Roles = "Admin")] 

Я, вероятно, misih логики, как сделать роли видна пользователю. Наверное, недостаточно, чтобы просто иметь роли в списке претензий?

ответ

4

Если служба использует проверку подлинности Windows, то IPrincipal.Identity вы получите, будет иметь тип WindowsPrincipal. Это немного вводит в заблуждение, но ClaimType что WindowsPrincipal.IsInRole() ищет не ClaimTypes.Role как можно разумно ожидать, но ClaimTypes.GroupSid.

Однако вы не должны принимать фактический тип ClaimType, который использует текущая идентификация для указания ролей, поскольку разные типы идентификаторов используют разные значения. Вместо этого вы должны указать свойство ClaimsIdentity.RoleClaimType.

Мы внедрили IAuthenticationFilter по следующим направлениям:

public Task AuthenticateAsync(HttpAuthenticationContext context, cancellationToken) 
{ 
    var principal = context.Principal; 

    if(principal.Identity is ClaimsIdentity && principal.Identity.IsAuthenticated) 
    { 
     var ci = (ClaimsIdentity)principal.Identity; 
     // get the user's additional roles from somewhere and add Claims 
     ci.AddClaim(new Claim(ci.RoleClaimType, "MyRole")); 
    } 
} 

Это позволяет использовать стандартный механизм AuthorizeAttribute в наших ASP.Net контроллеров. например

[Authorize(Roles="MyRole")] 
public IHttpActionResult Get() 
{ 
    //authenticated and authorised code here 
} 

См. ClaimsIdentity.RoleClaimType на MSDN для уточнения подробностей.

Обращаем внимание:, добавляющий определенные пользователем роли в WindowsPrincipal, может вызвать проблемы. Похоже, что текущая реализация .NET Framework 4.5 (по состоянию на апрель 2017 года) иногда вызывает исключение при проверке ролей, ожидая, что детали роли будут доступны из Active Directory. См. this question для альтернативного подхода.

2

Вероятно, ClaimType претензии является просто «ролью».

Вы должны создать заявку с помощью Microsoft Schema:

manager.AddClaim(dn1.Id, claim: new Claim(ClaimTypes.Role.ToString(), "ADMINISTRATOR")); 

Тогда User.IsInRole("Admin"); и [Authorize (Roles = "Admin")] будет работать должным образом.

Это потому, что Microsoft Identity использует схему:

http://schemas.microsoft.com/ws/2008/06/identity/claims/role

Когда для роли проверки. Я предлагаю вам проверить базу данных ASPNETIdentity, чтобы иметь полное представление о том, как вставляются требования к che. Я уверен, что свойство ClaimType для AspNetUserClaims не похоже на схему Microsoft.

С уважением

0

TL; DR Чувствительность к корпусу, возможно?

Я обнаружил, что проверка по умолчанию используется в ...

[Authorize(Roles = "RoleA,RoleB")] 

... был чувствителен к регистру.

Я создал роли в смешанном футляре и использовал диспетчер идентификации AspNetCore с реализацией не-EF-памяти для тестирования.
UserManager.IsInRole ("RoleA") верн. True, но при проверке через ClaimsPrincipal HttpContext.User.IsInRole ("RoleA") возвращает false. Я сбросила требование к тексту и могла видеть, что есть роль требование по правильной схеме MS ...

ClaimType:[http://schemas.microsoft.com/ws/2008/06/identity/claims/role], ClaimValue:[ROLEA], Issuer:[TokenServer] 
    ClaimType:[http://schemas.microsoft.com/ws/2008/06/identity/claims/role], ClaimValue:[ROLEB], Issuer:[TokenServer] 

... но значение утверждения (роль) было в верхнем регистре.
Чтобы устранить эту проблему, я просто должен был изменить атрибут ...

[Authorize(Roles = "ROLEA,ROLEB")] 

... и это сработало.

Итак, если у вас возникли проблемы с получением разрешения на работу для работы в AspNetCore, попробуйте прочитать претензии и точно соответствовать утверждениям. Вы можете прочитать требования на доступ к объекту HttpContext.User.Claims ...

 foreach (var claim in HttpContext.User.Claims)    
      Console.WriteLine($"ClaimType:[{claim.Type}], ClaimValue:[{claim.Value}], Issuer:[{claim.Issuer}]"); 

Это может быть, конечно, что я как-то осел кодировкой роли в верхний регистр, или где-то использовал NormalisedRole, но вы могли бы сделали то же самое ...

Смежные вопросы