Clarification: intended design for User Groups, Roles, Strategies, LDAP and Address Book ACL

[trofen]

Hi!

I’m currently working on the unfinished User Groups / Roles parts of the admin panel and ran into a design question.

At first, I started implementing this according to my own expected workflow, but after looking at the existing UI and data model, I’m not sure I fully understand the original design intent.

Currently, the admin UI already has separate sections for:

• Roles look like they should describe admin/backend permissions: what a user is allowed to do in the console.
• User Groups look like they should group users. Are they just a batch of users for future mechanisms? Same question for Device Groups.
• Strategies look like centralized RustDesk client/device configuration policies. I have not seen this in rustdesk-api, so I’m not sure I fully understand how this is supposed to work. I’m also not sure why this is called a strategy rather than a policy.
• Address Book rules: I did not find them. Ideally, there should be some mechanism that links ABN and AB with users/user groups through some access permission.

In rustdesk-api, every user inherited access from a single group, and that feels too limited. A more flexible model is needed for administration.

So before going further, I’d like to clarify the intended model.

Questions

1. So what exactly should be in Roles? What should this entity be responsible for?

2. Where should the user-to-group linking happen? It feels logical to assign the groups a user belongs to in the user management interface.

3. How do strategies work? To whom and where are they applied, and how are they related to Device Groups? Also, honestly, do we really need Device Groups?

4. Ideally, there should be a many-to-many table where:

   • column 1 is an ABN (address book) or AB (node in the address book);
   • column 2 is a user or user group;
   • column 3 is the access permission.

   As a result, the effective access permission should be calculated and used to determine how the web server shares data with the user.

   In the future, it would be interesting to fork hbbs and add ACL there, similar to RustDesk 1.5.0.

P.S.

The project is interesting, even though I’m a Go fan. The only disappointing thing is that the project still feels immature and too little has been implemented so far.

If we find the courage to bring the project to a fully working MVP in the near future, I’d be happy to try it in production.

I have needed fine-grained permissions, password policies for users, and TOTP for a long time.

[trofen]

@IamTaoChen, I’d like to ask you to join this discussion and clarify how you see the access-control model inside the project.
I think it would be useful to understand the intended design before I continue implementing things based on my own assumptions.
One important point is possible LDAP integration. Ideally, the access model should be designed in a way that LDAP/AD support can be added later without introducing a lot of workarounds.
I personally have not worked much with LDAP and I do not currently need this functionality for my own use case, but I think it is important to consider it early.

[YuZhiYuanDev]

@trofen
I am very pleased to discuss these issues with you.

In fact, at present I haven't come up with a good way to manage user groups or roles. The UI and data model you see now are just placeholders introduced during the initial imitation of the RustDesk Server Pro project. To be honest, I have no prior experience designing permission management models, nor do I know what real users or administrators actually need. Therefore, this feature has not yet been implemented. In our subsequent discussions, we can completely ignore the existing content on this matter.

Let me first talk about device groups. This is a feature supported by the RustDesk client, so I have also introduced the corresponding API interfaces and management options. I suspect that the official RustDesk design intention is to group devices for easier configuration distribution, and to assign device groups to users for management, thus avoiding the tedious process of assigning device permissions to each user individually.

The policy feature is also officially supported by the RustDesk client, allowing the admin side to push configurations to clients. For the specific implementation, you can check the /heartbeat interface code and the implementation within the RustDesk client. Currently, policies can be assigned to devices, users, and device groups. The RustDesk Server Pro project also supports this functionality.

Once user groups are implemented in the future, the address book feature will indeed work in concert with them to enable better management.

As for the expected model for user group/role management, could you first share your thoughts? What kind of model do you think would be suitable for actual management needs? Since this is a new project with no technical debt, I simply hope to design a management panel that is as perfect as possible and meets everyone's needs. I would very much like to know your thoughts.

Right now, I am working on integrating the hbbr and hbbs components with the management panel to support device enable/disable and future advanced access control based on user groups/roles.

Indeed, you are right — this project is not yet mature. But after all, the RustDesk Server Pro project has been under development for several years, while our project is only a few months old. I believe we still have significant room for growth. The reason I publicised the project so early is that we need the support of more developers. On my own, I cannot complete such a complex project. I hope we can work together to advance the project to a fully usable state.

Also, the TOTP feature has already been implemented — feel free to give it a try.

[IamTaoChen]

Hi @trofen,

Sorry for the late reply. I’ve been quite busy recently.

Regarding LDAP, I think we should use it only for user authentication and, at most, for checking admin roles (by mapping LDAP groups to local roles).

If we want to reuse LDAP groups, we can build a mapping between LDAP groups and local groups (roles). We shouldn’t directly manage or modify users and groups in LDAP.

[OCMan2K]

Is there a way to make only connection possible to users with admin rights logged to the console, I mean, i don't want to go in all the rustdesk client and log them to the console, only admin and IT support needs to connect to conputer,
so standard users not logged with their account to the console are not allowed to take control of computer ( but console is populated in their client settings, only no account ) .
Or maybe i can try deploying their client with a generic AD account ( rustbasic on my AD for exemple ? )

[OCMan2K]

Hey all, I’ve just merged @yardbirds0’s PR, which adds initial support for user groups.
Huge thanks to @yardbirds0 for the work!
Feel free to review and suggest any improvements.

[OCMan2K]

Hey all, I’ve just merged @yardbirds0’s PR, which adds initial support for user groups. Huge thanks to @yardbirds0 for the work! Feel free to review and suggest any improvements.

Sorry to ask it again, I need to find a solution to that to make RustDesk in production in my environnement :
Is there a way to make only connection possible to users with admin rights logged to the console, I mean, i don't want to go in all the rustdesk client and log them to the console, only admin and IT support needs to connect to conputer,
so standard users not logged with their account to the console are not allowed to take control of computer ( but console is populated in their client settings, only no account ) .
Or maybe i can try deploying their client with a generic AD account ( rustbasic on my AD for exemple ? )

[YuZhiYuanDev]

Sorry for the late reply—I'm in my final year of high school, so many exams!
#159 (reply in thread)