How does one differentiate between a feature flag and an authorization role?

Question

I'm working on moving some of our flags to a 3rd party system but I kinda have a hard time, determining what should be a feature flag and what should remain as authorization permission to a particular user. So wanted to ask, intentionally with less context on the type of flags I'm dealing with since it varies for each one. What is the rule of thumb you guys apply to classify?

Answer 1

This is all a matter of perspective. A feature flag (or feature toggle) is meant to hide a new feature from end users. This topic gets more complicated as you start adding the management of a feature, from its initial rollout to beta testers, all authorized users, and finally deprecating the feature once it is obsolete. It might be more clear to talk about authorization instead.

Authorization is a deep topic, but it all comes back to business rules and security. Closing a customer account is a feature, but more specifically closing a customer account is a feature only authorized users should be doing. This implies a subset of users can perform this action. If unauthorized users perform the action, it would be seen as a violation of business rules. In the worst cases, it could be a violation of law, breach of contract or lapse in security. The consequences of an unauthorized user performing an action are drastically different than if you accidentally showed a new search field to an unsuspecting end user.

Feature toggles could be used in conjunction with authorization. For example, if your team just built the "Close Account" feature, you could hide that behind a feature toggle. The code should also be performing authorization checks, regardless of the state of the feature toggle.

Simply because a subset of users can access a feature does not mean it is an authorization role. For instance, you could have a small group of beta testers, and only turn the feature toggle on for those initial users. This is not authorization.

Whether or not something should be represented by a feature flag or authorization role is determined more by the consequences of doing or showing something at an inappropriate time. If policies, laws or contracts are broken, it is an authorization role. If the user is permitted to do something (by policy, law or other business rule), but it is new functionality, then it would be a feature flag.

When in doubt, consult a subject matter expert. Do not make this decision on your own.

Answer 2

In my software, I have feature flags, I have features that are disabled because of device security settings, and those can sometimes be changed by the user. And features that are disabled by a configuration on the server, and some of those the user could change (by asking their admin) and some that they can’t.

Your (or your team’s or your UI team’s) first decision is what disabled feature you want to show to the user. Say ability to take a photo, and when the user taps the button, they get an alert “You can’t take photos. Enable camera use in your application settings”. Or “…, you can’t enable this” etc. On the other hand, there will be features that you want hidden if not available. Most most likely anything behind a feature flag.

To actually use the feature, you have one function per feature that checks feature flags if present, user permissions etc. and tells you if the user can use the feature. All in all I suggest:

1. One function that tells you if the feature should be invisible in the UI, visible but disabled, or visible and enabled.

2. One function that checks if the user is allowed to use the feature, giving feedback why not and how to change this.

3. One function that checks if the user is allowed to use the feature, as a guard to prevent use, without feedback. 2. and 3. can be combined by adding a parameter “giveFeedback”.

99.99 percent of your code will never know why the decision was made. It will check whether UI should be invisible, disabled or enabled. It will ask if a feature can be used, with or without feedback, and use that to block the feature. That’s it.

Answer 3

Many misuses of Authz in this question and the answers.

There is no such thing as "authorization permission" or "authorization role"

What is Authz?

Authz is a challenge, and activity/action - not a thing, not a result. "role" or "permission" are entirely separate concepts.

Authz is not assigning users groups/roles and checking if they are in a group/role when they try to do something, these are a form of ACL, specifically GBAC/RBAC) which are similar to other ACLs like ABAC/OrBAC and none are Authz

Is prompting MFA on login Authz?

No that just the Authn process plain and simple.

If I were to be convincing to readers; Consider the login action. It allows any anonymous user as having the 'authority' to use login. To be successful as an anonymous user with the login action you must complete the Authn mechanism/s which decide if the anonymous user is allowed to complete the login action to prove their 'identity'. Once identity is proven something like a HTTP cookie or JWT can be provided as a trust mechanism for the next time the (now authentic identity) want's to perform another action.

When you attempt to do anything at all as an authentic user (for demonstration purposes, see your own user data at https://example.com/me) you present your trust token (cookie/jwt/other) and the server can then decide to trust you, and then decide using an ACL if your identity can access the resource at /me on example.com (maybe the cookie is for bar.foo.com or the JTW aud is for an unknown party, these should be denied). Therefore when you have sdone Authn and you present your token of trust, the server is not ausking you to perform any type of Authz mechanism at all, it trusts or distrusts.

So when is Authz used?

When you attempt to do something with elevated privileges; an example is the personal bank account, you can do many things that trust after Authn permits, you are authorised to look at many types of data and even transfer money to accounts that have been trusted prior. But when you try to do a bank transfer to an account you have never sent money to before the Bank requires that you complete a challenge-response mechanism typically OTP via SMS

When you are prompted to perform the OTP challenge and are successful with your response code, the bank will then authorise you to transfer money to that new external account

This is Authz!

So do you have Authz?

Is there anywhere in your program that prompts a user for Authz challenges when they try to do something sensitive?

The answer in most cases in no, therefore you have no Authz mechanisms at all and likely thought you did

OWASP Top 10 didn't put Broken Access Controls at the #1 spot for no reason, many people talk about Authz and do not actually understand it and think they do.

It is dangerous.

So the answer to the OP

Does the 'feature' need elevated privilege? If so, this is where you need to perform Authz

If the feature is not sensitive, that an authentic user (one that has proven Authn and is trusted) can access the feature at the same security level as all otehr features that also do not require elevated privilege, then this feature flag like all others will not be requiring Authz because the challenge-response mechanism of elevated privilege is not required.

Answer 4

Does it vary by user? If so, it's a authorization role. If it doesn't, it's a feature flag.