-1

I understand Role Based Security. I have read about Policy Based. I have read what others call Activity Based.

What I want to know is if I do Policy-Based, am I avoiding what Role-Based requires and what Activity-Based seems to avoid - hardcoding security, refactor because of some new requirement, hardcode some more, and so on.

I see the difference between Role and Activity based. And my goal is to not have groups hard-coded in a method like Admin, SuperAdmin, SuperSuperAdmin, etc.

I think but am no sure if Policy Based does what I want, but I cannot understand how. How are these three different?

If I use the Under21 example for Policy Based I have seen many times on various blogs, I have:

[Authorize(Policy = "AtLeast21")]

How is this different from:

[Authorize(Roles = "SuperAdministrator, ChannelAdministrator")]
public class ChannelAdministrationController: Controller
{
}

And Activity Based (is this Context Based?) is different but appears more "semantically" accurate. You have an UpdateUser Activity, and it is probably not likely you'd have SuperUpdateUser Activity. But with policies, it seems you could have the same as multiple roles. I know there can be many Claims used the authentication and authorization, but all I can think is there might be a better name than Over21 for my policy and create a role that my Claim needs. But somewhere in the back, I have to create those activities and roles and users. Even Role Based has policies I can use in .NET Core Middleware, so I am confused.

For example, I could just as easily require an additional policy,

[Authorize(Policy = "AtLeast21", "ExceptInTenneseeWithParent", "ExceptInChurch")]

Is this my answer (from the MS page)?

services.AddAuthorization(options =>
{
    options.AddPolicy("BadgeEntry", policy =>
        policy.RequireAssertion(context =>
            context.User.HasClaim(c =>
                (c.Type == ClaimTypes.BadgeId ||
                 c.Type == ClaimTypes.TemporaryBadgeId) &&
                 c.Issuer == "https://microsoftsecurity")));
});

I am back to hardcoding requirements again.

My question is how are these different?

Additionally, does policy-based security keep me from having to add a new role or policy everytime something new comes along (see my examples above). Activity based does (it seems).

"Why do you believe that Role-Based Security is tightly coupled, while Policy-Based Security is not?"

I am not sure it isn't. That is why i am asking because something isn't adding up to me. While this isn't good,

[Authorize(Roles="Administrator, SuperAdministrator, 
CertainBosses, SomeGuyinHR, SuperDuperAdministrator")]

I am not convinced policy is better,

because I have to change my handler with conditionals. The only thing I can think of is in the Policy-Based you can have a more self-documenting set of code that doesn't change based on a new security role.

[Authorize(Policy="UpdateUser")]

and in your policy you either,

...administrator || some_user || something else

or some new policy stacked

[Authorize(Policy="UpdateUser")]
[Authorize(Policy="UpdateUserIfYouAreX")]

or in the database

...is the user in the database that has my roles

and change all my role information in the database.

Activity-Based seems most similar to the last policy design:

(from lostechies)

[HandleError]
 public class HomeController : Controller
 {
     [Authorize(Activity = "Administrators Only")]
     public ActionResult AdministratorsOnly()
     {
         return View();
     }
 }
  • 1
    Is your question why these things are different, or how you can do it without hardcoding? – Robert Harvey Jan 11 '18 at 18:56
  • They are different because role-based security deals with defined roles, while policy-based security imposes conditions (like age >= 21). The age of a person is not a role; it is a characteristic of the person. – Robert Harvey Jan 11 '18 at 18:58
  • @RobertHarvey My question is more about trying to solve the tight-coupling that Role Based gives. I will see if I can reword the question. – johnny Jan 11 '18 at 19:08
  • 1
    Why do you believe that Role-Based Security is tightly coupled, while Policy-Based Security is not? Or, to ask the question a different way, where do you perceive tight-coupling to be occurring? – Robert Harvey Jan 11 '18 at 19:16
1

Your question seems to hinge on the idea that the Authorize attribute in

[Authorize(Roles = "SuperAdministrator, ChannelAdministrator")]
public class ChannelAdministrationController: Controller
{
}

needs to be configurable. It doesn't. Those roles are unlikely to ever change. What is more likely to change are the roles that are assigned to a particular user.

If I use the Under21 example for Policy Based I have seen many times on various blogs, I have:

[Authorize(Policy = "AtLeast21")]

How is this different from:

[Authorize(Roles = "SuperAdministrator, ChannelAdministrator")]
public class ChannelAdministrationController: Controller
{
}

From the standpoint of maintainability, they aren't different. Changing either one requires a change in code. However, if it's just a matter of changing the age, you could do something like this:

public void ConfigureServices(IServiceCollection services)
{
    // get minimum age from some configuration service or class
    var age = configuration.GetMinimumAge();

    services.AddMvc();

    services.AddAuthorization(options =>
    {
        options.AddPolicy("MinimumAge", policy =>
            policy.Requirements.Add(new MinimumAgeRequirement(age)));
    });
}

And then, if you want to change the minimum age, you can just change the value in the configuration, rather than changing the code and re-deploying, although a restart of the web application might be required to pick up the change.

  • The roles might not change that much. It's the exceptions that do. There's always this one group or person that needs something special that requires going back and adding their group to the attribute. – johnny Jan 11 '18 at 20:56
  • OK. And ..... ? – Robert Harvey Jan 11 '18 at 20:57
  • And I'd have to go back and add new roles and recompile. I have had things with all kinds of exceptions the older an application gets, people change jobs, etc. – johnny Jan 11 '18 at 20:57
  • If you're making such adjustments in your code, you're doing it wrong. Any such adjustment should be possible by changing the roles, activities and attributes of the users themselves (which can be done in configuration), not the structure of the application with respect to Authorize attributes (which must be done in code), unless the application itself is wired incorrectly for the organization's needs. – Robert Harvey Jan 11 '18 at 20:59
  • 1
    Yes, but that's considered a new software feature, in which case a code change is entirely appropriate. The fact that you seem to be doing that a lot indicates either that there is a problem with the application's design, or that the organization's structure is ill-defined. – Robert Harvey Jan 11 '18 at 21:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.