Feature Flagging vs Authorization

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?

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.