Integrating RBAC for StreamPipes permission management

[RobertIndie]

Hi all, I propose we initiate a discussion about integrating Role-Based Access Control (RBAC) into StreamPipes.

Motivation

We currently have a permission management system, but it seems to exhibit several limitations:

• Adapter Permission Gap: At present, we only validate admin permissions for the adapter API. So the permission management of the adapter seems not working. Seems we couldn't share the adapters with other users.
• Lack of ConnectUser Role: There is no ConnectUser role. Is there a specific reason we don't have a ConnectUser role?
• Inadequate Permission Granularity: When sharing resources like Pipelines or Adapters, our permission system seems too broad. Ideally, we should be able to specify Read, Write, etc., permissions when sharing resources.

Objectives

My proposal is to adopt a new approach to permission management in StreamPipes. By using RBAC, we can revamp our current permission management and introduce granular control over permissions for all resource types. This would enhance precision in resource sharing. I hope to replace the existing system with this new one to avoid maintaining two systems and adding unnecessary complexity. We may also need to consider backward compatibility in this transition.

Proposed Method

I suggest using Casbin to implement RBAC. We can utilize jCasbin and the RBAC with resource roles model for this purpose.

WDYT of this idea. I would like to hear your feedback. Then I could research and share more details of this proposal. Thanks!

[dominikriemer]

@RobertIndie that's a great idea and would be very useful to have!
Concerning the ConnectUser role, I'm not 100% sure, but I guess we don't have that role because when the role management was introduced, Connect didn't support anything else than creating adapters (no modification and no metrics views) which could have been assigned to the ConnectUser roles. With the current state, having a ConnectUser role which only can view created adapters and metrics would definitely make sense.

So I'm fully +1 for revamping the permission management system!

[tenthe]

Hi @RobertIndie,
Thank you for initiating this discussion. I think it's a very good idea.

I have no experience with Casbin, but I am in favor of introducing a library that provides the necessary functions. Have you had any experience with this?

Given the scope of this change, I'm thinking about how we can break it down, especially because we need to ensure backwards compatibility to achieve the upgrade of existing installations.

Here are two questions to keep the discussion going:

• Do we need to refactor something before we integrate RBAC?
• Would it be a good idea to develop a small prototype first so that we can familiarize ourselves with the library and its concepts before tackling a system-wide migration?

I look forward to hearing your thoughts on this

[RobertIndie]

I'm writing the prototype to demonstrate it.

Do we need to refactor something before we integrate RBAC?

I'm investigating it. But ideally, I don't think we need to refactor too much for the existing codes.

Given the scope of this change, I'm thinking about how we can break it down, especially because we need to ensure backwards compatibility to achieve the upgrade of existing installations.

My rough idea is to revamp the current permission control logic using the new RBAC implementation. After that, we could develop more features based on RBAC. Such as we could introduce the role management for StreamPipes.

We need to use a dedicated document in couchDB to store the RBAC policies. Therefore, we need to provide a script for users to transfer the permission-related documents to new RBAC policies document before upgrading to the new version.

Do you think it would be too risky to replace the existing implementation? Should we introduce a configuration to let users decide which implementation to use?

[tenthe]

I don't think it's too risky to replace the existing implementation. We should "only" make sure that we migrate the existing authorizations correctly to the new version. We can use the migration scripts to do this.
I look forward to the new feature.

[luoluoyuyu]

Hi @RobertIndie
This is a great idea and I think multi-tenancy can be achieved on top of RBAC. For example, the concept of namespace is introduced to realize resource isolation at the software level.

[RobertIndie]

+1. We can abstract a layer like the resource group in the RBAC model.