Why isn't [Authorize(Roles = “Admin”)] working in MVC 5 RTM with ASP.NET Identity?

Question

Does [Authorize(Roles = \"Admin\")] work out of the box in MVC 5 RTM with ASP.NET Identity?

I\'ve had no luck. Note that [Authorize] and

Answer 1

<system.webServer>
<modules>
    <remove name="RoleManager" />
</modules>
</system.webServer>

Answer 2

And the answer is the UserManager's DbContext must have lazy loading enabled in order for user roles to manifest in the application in the usual, expected, way. As it turns out, not all of my code was "out of the box." I had customized my DbContext ever so slightly. Hopefully in the future Microsoft will sidestep this integration bug by ensuring the collection is loaded with something like userDbContext.Users.Include(o => o.Roles).SingleOrDefault(...).

• DO: ApplicationDbContext.Configuration.LazyLoadingEnabled = true;
• DO NOT: ApplicationDbContext.Configuration.LazyLoadingEnabled = false;

Note that if ApplicationDbContext.Configuration.LazyLoadingEnabled is not set in your code then it defaults to true. So leaving off that line is as good as setting it to true.

Etc.

Here's my guess at what is going on when lazy loading is disabled, the Roles property of the IdentityUser / ApplicationUser object is null or empty when the UserManager or UserStore accesses it because that collection was not manually loaded. The code then carries on like no roles have been assigned to the user when in fact that collection simply was never loaded.

Ah, the aroma of silent failure. Had the code only made some noise when things didn't look right.

Answer 3

The user may need to be re-authenticated to receive new claims that include membership in the Admin role. Since MVC 5 uses ASP.NET Identity out of the box, and by default in MVC 5, ASP.NET Identity stores claims like roles in the user's cookies, that information can become stale (hence the database says one thing but the user's cookies say something else). Re-authenticating a user will refresh their claims, including user role claims, to match the current state of the database.

For example:

If a user signs in before being assigned to the Admin role in the database that user will be granted claims but they will not include their assignment to the Admin role. If later, they are added to the Admin role, the claims stored in their cookies are not automatically updated. Instead only the database has been update, the application has to re-authenticate them before their old claims will be replaced with the new claims that include membership in the Admin role. Having the user manually sign out and back in, is the most obvious way re-authenticate that user.

Here's an article on Using Claims in ASP.NET Identity