DEV Community

loading...
Cover image for Role-Based Security using Entity Framework (Part 1) | Dear Coder

Role-Based Security using Entity Framework (Part 1) | Dear Coder

Kasey Wahl
developer | tech blogger | language lover
・3 min read

Dear Coder,

If you're working on an application that allows users to register an account, you've likely encountered the issue of role-based security.

What is role-based security and why do we need it?

Say you're working on an application that allows users to share webcomics with each other. You've already built in the features that allow the user to securely upload photos to your database, and you've implemented features that allow users to register an account and log in.

But now you need to ask what features should be accessible to any user regardless of if they've registered an account, what features should be accessible to registered users, and what features should be available to privileged users.

This is where role-based security comes in.

For the sake of my illustration, let's categorize users into four tiers of access:

  1. anonymous (unregistered) users
  2. registered users
  3. Moderators
  4. Administrators

Anonymous User Authorizations

By default, my application allows any user to see, interact with, and use any of the pages on my application.

But what pages should anonymous users be able to see?

As a general rule, landing pages and displays of publicly-available data are fine for anonymous end-users to see.

Some developers may maintain applications that contain a large amount of sensitive data, however, which means it might be appropriate to refactor the application's default authorization.

We can do this with some interplay between the [Authorize] and [AllowAnonymous] attributes.

But more on anonymous users later.

Registered Users

Let's back up and talk about the [Authorize] attribute.

If I want my application to handle uploads, it's in my best interest to deny anonymous users access to some of my views. I can do this with a simple keyword called "Authorize"

To prompt a user to register and log in to see a View, I need to access the controller that handles the get and post http requests for the Views I want to authorize.

To illustrate, let's look in my ToonSpace webtoons application, and access the Uploads controller.

I don't want anonymous users to be able to upload to my website, so I need to make a small change under the "get" action by adding [Authorize] above the action.

Get Create Action

This simply ensures that only users who have registered an account and are logged in can access the "Create" view to upload something new to the database.

Moderators and Administrators

I've grouped moderators and administrators together because the code for my Moderator and Administrator permissions is essentially the same. The only differences are discretionary. I grant some permissions to both roles and others to just the Administrator.

So how do I grant special permissions to these roles?

Just a few simple lines of text:

Administrator Auth

To authorize a moderator as well, I simply add a comma:

[Authorize(Roles = "Administrator, Moderator"]
Enter fullscreen mode Exit fullscreen mode

I've created the structure for role-based security. Any user may create an account and log in, and anonymous users are not allowed to post anything. But what if I want to set the default to allow anonymous users to post something (like a comment)? I can simply use the [AllowAnonymous] attribute.

And what about these Administrator and Moderator roles? How do I differentiate between which users are in these roles? Should anyone be allowed to sign up as an Administrator or Moderator?

I'm sure you already know, dear Coder, that allowing the user to sign up as an Admin is probably not a great idea. What I can do instead, however, is "seed" a designated user as an Administrator or Moderator.

But that will be the topic of my next letter.
If you'd like to read more letters, you can find them at dear-coder.com.

Until next time, godspeed in your keystrokes.

Clickity Clacks,

Kasey

Discussion (0)