Feature Flagging vs Authorization

Question

I just stumbled across the concept of feature flagging, and a popular open source Java lib for this called Togglz, which quotes a Martin Fowler blog post:

The basic idea is to have a configuration file that defines a bunch of toggles for various features you have pending. The running application then uses these toggles in order to decide whether or not to show the new feature.

But to me, this really sounds like authorization: Is the user authorized to view this content?

For example, Should the user be able to see the FizzBuzz menu, or not?

In Togglz I might implement this check like so:

if(MyFeatures.ShowFizzBuzz.isActive()) {
    // Show the FizzBuzz menu.
}

In, say, Apache Shiro, I could do the exact same thing:

ShowFizzBuzzPermission showFizzBuzz = new ShowFizzBuzzPermission();
if(currentUser.isPermitted(showFizzBuzz) {
    // Show the FizzBuzz menu.
}

Again, feature flagging just feels like its the same exact problem as role- or permission-checking.

I'm sure I'm wrong, but I don't see how. So I ask: How is feature flagging different than authorization and role/permission checking, and what types of concrete use cases exemplify this difference? In other words: When should I use authorization/role/permission checking, and when should I use feature flags?

Grivet

Answer 1

I'm going to use Mr. Fowlers terminology for the two types of Feature Toggles:

• Business Toggle: would be features that are long-lived configuration where all states are supported.
• Release Toggle: Meant to help transition from an old or nonexistent implementation to a 'new' one. The intent with this one is to retire the old way of working when the work is done. This enables you to when you want to preserve the current way of working while the 'new' way is unfinished. Most people agree these should be avoided when possible.

How is feature flagging different than authorization and role/permission checking, and what types of concrete use cases exemplify this difference?

I think authorization and role/permission checking are configuration underneath the implementation of a Business Toggle. Authentication is your Business Toggle feature, Shiro would be a tool that helps you configure and enforce your authentication feature. Togglz is an framework for the implementation of Business Toggles or Version Toggles. It could be used for an authentication feature

If you used Togglz to turn on/off authentication, and then Shiro to enforce a user's configuration, your code would look like this:

if(MyFeatures.ShowFizzBuzz.isActive()) {
  ShowFizzBuzzPermission showFizzBuzz = new ShowFizzBuzzPermission();
  if(currentUser.isPermitted(showFizzBuzz) {
    // Show the FizzBuzz menu.
  }
}

You may choose to forget the Feature Toggle, because you always want authentication ON. The toggle is just introducing an additional check and technical debt.

When should I use authorization/role/permission checking, and when should I use feature flags?

I think this decision is up to you. I would say that authorization is a feature, and you could use Shiro to implement it. Your application could have many other features that would go beyond the scope of Shiro, and make you want to use Togglz to turn them on and off. I argue that any complex feature will still require configuration to drive your business logic.

Sarette

Answer 2

I won't answer for logic behind Togglz. In FF4J documentation (feature flipping for Java), you could find a cristal clear schema which explains the difference.

A feature is a treatment, a function which could be enable and disable at runtime through dedicated web console. This should the main driver to toggle your code : Does I need to activate/desactivate through configuration ?

Once you identify Feature Toggle mechanism would have great value (you can pick up some use case in the bottom of ff4J.org page) you can check permissions.

Checking permissions in a Feature Toggle context is meant to perform a "Canary Release" : open a new feature for limited subset of users before opening for everyone.

Vally