ASP.NET Identity check user roles is not working

Question

I have an ASP.NET MVC 5 application. I'm using the standard ASP.NET Identity provider for user and role management. It is important that I'm using the IdentityUser from an own repository project, but this seems ok. I can register, login, edit users, and manage their roles.

I add user to Role with these lines:

UserManager.AddToRole(userdetail.Id, r);
db.Entry(userdetail).State = EntityState.Modified;
db.SaveChanges();

This seems working in DB level.

But, I can't use Role based authentications, actually the simples

HttpContext.User.IsInRole("Administrator")

doesn't working too.

[Authorize(Roles="Administrator")]

doesn't working too.

I can check only with this method, whether user is an administrator:

UserManager.IsInRole(userID, "Administrator").

Why?

In every tutorial what I found, everything works fine. The different project repository could be the reason? Or ASP.NET Identity is broken so much?

Please advice,

Goliard

The answer has been posted. Accept it. The one by jd4u. – Conservancy

Answer 1

There seems to be an issue. [The issue by design]

• The role names are case sensitive in AuthorizeAttribute and User.IsInRole
• The role names are case insensitive in UserManager.IsInRole

Moreover, check for the correct role name is used for the verification.

[The above is based on the test performed with below code. Role Name="Admin", User is added to Role "Admin".]

[Authorize(Roles="Admin")] /*True as "Admin" has A capital as entered in Role name*/
public ActionResult Secured()
{
    if (User.IsInRole("admin")) /*This is False*/
    {
         Console.WriteLine("In");
    }
    if(UserManager.IsInRole(User.Identity.GetUserId(), "admin")) /*This is True!!*/
    {
         Console.WriteLine("In");
    }
    return View();
}

If we change the attribute to [Authorize(Roles="admin")], it redirects to Login page.

Gentianella

Do you happen to know how to bypass this cause i have the exact same issue. I use custom user and rolestore but im guessing should be noted but it works fine using the manager and not through User and annotation. – Icbm

This saved my life I don't know why this answer wasn't accepted. Nothing else mentions this. Go look up "Identity userinrole" on Google and you'll see the inaccurate "User.IsInRole" <-- doesn't work!! Sure they're old questions and ASP.NET MVC 5 is 2 years old now but oh well. If anyone is programming the original MVC 5 stack then this is it! Probably work for .NET CORE too. – Conservancy

Case sensitivity in this is just criminal, it must be a bug. I found this in my own code and only found this answer after wasting a nice chunk of time. Upticking your answer! – Rayleigh

I don't know why this answer IS accepted. I am using an Authorize attribute on a controller, casing is exactly the same as my role, spelling is exactly the same as my role, I am definitely assigned to the role (I've checked via RoleManager calls and looked at the db itself) and it's still not letting me in. This is in a .Net Core API project. – Reductase

@Reductase in this case, the original question specifically stated that the Authorize attribute and User.IsInRole did not work, but UserManager.IsInRole did. The known reason why these return different is case-sensitivity, i.e. this answer. In your case, it may be a different problem. Try and reproduce the original, i.e. check is UserManager.IsInRole works. If UserManager (case insensitive) does not work either, then you have a different problem that the original poster (e.g. cached data in cookie). – Asymptote

Answer 2

In that case you need to logout and login the user again.

Because the roles data is also stored in cookies, So you must issue the cookie again to work it.

Dinesen

You can also achieve same thing without having to log user in and out again by updating the security stamp. See https://mcmap.net/q/125335/-what-is-asp-net-identity-39-s-iusersecuritystampstore-lt-tuser-gt-interface – Latterly

Answer 3

For me none of the above solutions worked and almost non of the articles out there worked! The issue was that Authorize attribute searches for the role claim in the JWT token issued by identity server 4. And by default identity server does not serialize the role claims in the token on a new project with identity.

The bellow configuration was required to make this work. (ASP.Net 7 new Blazor web assembly project with identity)

builder.Services.AddIdentityServer()
.AddApiAuthorization<ApplicationUser, ApplicationDbContext>(options => {
    options.IdentityResources["openid"].UserClaims.Add("role");
    options.ApiResources.Single().UserClaims.Add("role");
});
JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Remove("role");

ps. This was also the most sleek solution since most articles out there required to override and implement your own Identity Server principal factories and add custom identity resources etc etc.

Outspan

Answer 4

Do you have this entry in your web.config?

    <roleManager enabled="true">
        <providers>
            <clear />
            <add connectionStringName="ApplicationServices" name="AspNetSqlRoleProvider" type="System.Web.Security.SqlRoleProvider" applicationName="/" />
        </providers>
    </roleManager>

Also, if I remember correctly, there is a different namespace for the role provider assembly in different versions of .NET.

Abbie

Are you talking about the latest ASP.NET MVC 5 with ASP.NET Identity? – Goliard

roleManager is for role provider (msdn.microsoft.com/en-us/library/…) it's basically deprecated and is not ASP.NET Identity as requested – Farrish

Answer 5

I was using IsInRoleAsync in Asp.Net core and in my case the problem was that I had ignored the role's normalized name when I created it. Therefore, after updating the normalized name for the role everything worked properly.

Kellam

Answer 6

I had the exact same problem with a .net 7 webapi project. Here's what I found:

The role names in the jwt token are NORMALIZED, since the Athorize Attribute is case sensitive, I have to use [Authorize(Roles="ADMIN")] instead of [Authorize(Roles="Admin")] for roles to work.

I finally had all my role names set to upper case to avoid this trap.

I think JwtSecurityToken generation method use the NORMALIZED role name to generate the JWT token is the root of my problem.

Anyway, I think the Authrize Attribute and JwtSecurityToken should give us a case sensitive option, or at least warn us about this case sensitive comparison algorithm.

Nato