App Specific Roles

[m-braha]

Is your feature request related to a problem?

The goal is allow someone elevated permissions in one app but restricted permissions in another. This would allow use cases like:

• a development team lead getting elevated permissions in an app they own but regular developer permissions in another app they don't own
• creating a "common" app that holds shared secrets meant to be used across many apps, and letting limited read access to it while preserving developer permissions in the other apps they are apart of.

For example, I create a custom "App Admin" role that allows full access within an app (different from the built-in "Manager" role because e.g., some users shouldn't add members at the Organization level, but should at the app level). Alice, the lead of the Frontend group, gets the "App Admin" role for the Frontend app. She also sometimes supports the Backend group where she should really only get read access to secrets across all environments (via a custom "Reader" role)

Right now I don't think there's a way to express this. She would get App Admin access to an app she doesn't own because she was the App Admin of a different app.

Describe the solution you'd like

Perhaps Applications can override roles. The current system is kept, where users are assigned roles at the organization level, but within an existing Application the Role can be changed to another role. By default, it's the organization role and no other action is needed.

If a role is chosen within App, it gets saved to the Application state and on access control checks at the Application level, if a role was defined, that's used instead.

This could solve the use case above because we could assign Alice the different role in the app she doesn't own and it overrides her "App Admin" role. Though I suppose with app specific roles, Alice would be getting the "Reader" role at the organization level and for apps she owns, it gets overridden to "App Admin".

Simply doing role overrides means you can avoid having to compare individual permissions within a role and having to decide which to use in case of conflicts. But maybe there's other complications with this naive approach, not sure.

Describe alternatives you've considered

Giving people more access than they should, or duplicating secrets across many apps/environments.

For Service Accounts, it means creating very specific accounts and using the appropriate tokens for each. By providing multiple tokens to an external process, it can mimic the behavior of having multiple roles. But that doesn't apply to Users.

Maybe there's other options I haven't considered?

[rohan-chaturvedi]

Hey @m-braha, I this is a compelling use case. Thanks for the detailed description and examples!. The only complexity I see here is, as you guessed, handling permission conflicts. If a user is assigned an App Role, we would need to decide on whether to use a combined permission set of their Org + App permissions when performing actions within an App, or to simply allow the App Role to override all permissions. I'm in favor of the latter, since the goal here generally is to avoid over-permissionning, and since we're dealing with App permissions only, this shouldn't lead to any strange behavior.

We will also need to create a new permission class to control who can assign / change App Roles for users, as well as a place to define these Roles.

Do you think it would be good enough to allow these App Roles to be defined centrally for the Organization just like current Roles, and simply applied to users within an App, or should each App be allowed to create a 'silo-ed' set of App Roles?

[m-braha]

Creating the roles at the organization level means they can be shared across apps, which I like. Making roles within Apps that only that App can see sounds useful to maybe large enterprise organizations because it could offload some admin work to App owners, but I personally don't need it for my company.

Unless creating siloed roles within Apps is going to have large impacts on the design/implementation that should be considered now, I would push that feature to another time.