Feature: Add Permission authorization to RBAC

[robotdan]

Add Permission authorization to RBAC

Problem

The current implementation of RBAC does not offer granular permission authorization.

• Role assignment
  • A user can have many roles
  • A role can have many users
  • [missing] A role can have many permissions
• Role authorization
• [missing] Permission authorization
  • [missing] A user can have a specific permission

Solution

TBD

Workaround

Create more roles.

admin:
admin:thing1
admin:thing2
admin:thing3

Related

May be partially or fully resolved by issue #881

How to vote

Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.

[blanchonvincent]

it could be also interesting to extends the user management scope to the applications.
for example, we would like to give a user the « read only » permission to users that belong to one or many applications.

[marcpearson]

Any update about this feature ?

[robotdan]

Hi @marcpearson, no update to share yet.

We are currently swamped trying to keep up with our existing feature pipeline and pro-serve requests. If we can get enough interest in the feature, it is possible we'd get to it this summer.

If you're interested in us prioritizing this feature to build it out for you, you can use the contact form on https://fusionauth.io and we can put together an estimate for you.

[jkour]

Guys, this is a must feature for enterprise environments.

Any update on this?

[voidmain]

Hi @jkour. We just did our planning for the next 2 months and this feature didn't make it on to the roadmap unfortunately. If you have an immediate business need for this, we can bump something off the roadmap and implement this for you under a professional services contract. Otherwise, hopefully we can get to this over the summer. Feel free to reach out using the contact form on our website if you are interested in a professional services contract.

[carlreid]

Hey @voidmain, you mentioned getting to this over the summer. Does this still look likely to be implemented soon?

[voidmain]

This feature has a lot of upvotes, which is a great sign that it should be prioritized.

This year is a balance for us to ensure that we can generate revenue to sustain the company while still implementing features that are the most needed. I can see an implementation where this feature requires a license but I could also make a case for it being in the free version.

If we decide that it will go in the free version then it will likely be put on hold for another couple months since we are prioritizing paid features at the moment.

If we decide to make this a paid feature then I could see it being implemented in the next release.

Comments and thoughts on this decision are welcomed and appreciated.

[carlreid]

I'd say this is a fundamental feature that most people would look for when looking into solutions. That might also be why the likes are on the higher side.

If this was a paid feature, then how could someone test it out to ensure that it works for a given use case? Essentially that's what I'm trying to do right now with various providers.

Of course you guys need to earn something from your work but I don't think I'd have a good time trying to persuade someone in my company to pay for this. They'd likely argue that we could achieve the same with Azure AD by hacking around using a bunch of roles or something.

[voidmain]

The same could be said for FusionAuth. You could hack around this with a bunch of roles.

We are planning on adding a 14-day free trial to our Developer Edition, which will help with the "try it for free" situation. However, I don't know if we can justify adding free features unless the benefits are very clearly defined, both for your company and ours.

Clearly there are trade-offs that need to be considered, but this is a good discussion. :)

[carlreid]

The same could be said for FusionAuth. You could hack around this with a bunch of roles.

That's exactly what has already been suggested 😄

Unfortunately I don't really have any ideas on how you could monetize FushionAuth in general. I like the idea of "leveling" up that you seem to have already, for example with password breaches. I think that adds a lot of value that would be worth indeed paying for. You could also look at this feature as a level up too but I feel like it's more of a core part of the system as a whole?

Our use case is just to use FusionAuth (or something else) to manage permissions for a single application in our team. With integration with Azure AD. We don't really need anything more than that, so the way roles/permissions work is probably the most important.

I hope someone else can add some insight into their thoughts and opinions on the matter to help you guys out a bit.

[designermonkey]

IMO even if the idea of 'permissions' was not to be added, adjusting the current model to allow nested roles would be sufficient as this would cover the permissions base and allow for more granular control of roles.

I was thinking about asking for the nested idea with Groups also so a use case of Company -> Department could be applied.

I think that from a useability perspective this is a must to some degree, even if the UI did this and did the legwork behind the scenes to flatten out roles and user membership to them.

---

While we are happy to hack around this feature, it's not a long term solution, so whether it's a UI feature or an API feature, it's definitely a must to be a big player in the market.

[voidmain]

For everyone that has been following this feature request, please check out the new Entity Management feature that is available in 1.26.0. This allows you to define these classes of objects:

• Entity types (i.e. Company)
• Entity type permissions (i.e. ceo, user_manager, hr_admin, programmer, bro-grammar, etc)
• Entities (i.e. Pied Piper which is of type Company)
• Entity grants (i.e. Richard is granted ceo and programmer to Pied Piper)

This might cover a lot of use cases that this feature request would also cover. The current version does not fully support entity hierarchies, but the next version will. This will also allow you to build complex models and relationships and manage nested and cascading permissions.

@designermonkey - let me know if Entity Management fits your needs specifically or if you need permissions instead.

[designermonkey]

I know this may sound cheap skate, but being a paid for feature, no it doesn't fit our use case sadly. We're not in the position to be able to pay for non-community versions yet.

Thanks for telling us about it though.

[mooreds]

@designermonkey no worries, we understand that organizations have different needs that change over time!