feat: add multi-tenancy, enrollment tokens, branding, and UI improvements

[SteveKueng]

Summary

Multi-tenancy

• UserTenant model for user-tenant relationships with roles (admin/operator/user)
• Tenant members UI for managing users within tenants
• Tenant access middleware for permission checks
• Delete user-tenant associations when removing tenant

OIDC integration

• Auto-assign users to tenants via OIDC org ID
• Support OIDC project roles (admin/operator/user)
• Tenant OIDC settings UI (org ID, default role)
• Refactored OIDC role fields

Enrollment tokens

• Token CRUD with expiry and usage limits
• Config ZIP generation (openuem.ini + certificates)
• Platform-specific install scripts (Linux/macOS/Windows)
• Public API endpoints for agent enrollment (/api/enroll/:token/config, /api/enroll/:token/install)
• Download counting per token

Branding

• Logo uploads (light, small/favicon) as base64 data URLs
• Primary brand color customization
• Custom product name and login page customization

Depends on: open-uem/ent#(multi-tenancy PR), open-uem/nats#(enrollment-token PR)

[doncicuto]

Sorry about being late reviewing this, I'll try to save some time this weekend (some personal issues are devouring my time)

[doncicuto]

I've started to review and checkout the code for the different repos. I'm taking some notes and comments but I'll need some time as there are several nice features mixed in the PR and I surely will need to add some code to migrate to the behavior that you suggest.

Will post some comments here in the following weeks.

This will be an awesome addition to OpenUEM, thank you @SteveKueng for your effort and for sharing it with the project.

We'll see all these changes for the release 0.13.0

[doncicuto]

Hi @SteveKueng, again I'd like to thank your for your code. I'm enjoying to read and use it.

If you don't mind I've checked out the PR using the GitHub CLI that allows me to modify the code that you've sent. I don't want to be the common reviewer that say I like things like this and that, send it back to me. I value your time, so instead I'm doing some changes that allow me to test your PR.

One of the changes that I'd like to discuss with you is that probably I'm adding a superadmin role. I'll try to explain my logic. When I run your PR, I found that I could not see the list of tenants neither the settings icon in the navbar (and of course the rest of new settings like branding, enrollment...). The reason is that my user (I use certificates or user/pass auth) had no role assigned to it, so it wasn't possible to identify my permissions to see some of those things. The easiest way that I think we can migrate the existing installations, so every existing user can use OpenUEM until a role and tenant is assigned, would be to create a new role called superadmin. Every single user that is now in OpenUEM is an admin that can see every setting and tenant, so when the new console starts I'll have a task that will check if the user has a role assigned, and if no role is there the superadmin role will be added. I'd changed the middleware in my lab to allow that superadmin role to allow access to everything. The superadmin will therefore see everything and change the role of the rest of the users according to the tenants needs. The special admin and openuem users will have that role. Does this make sense to you?

Also this is the branding tab after some of the minor aesthetic changes that I propose:

[SteveKueng]

HI @doncicuto

My initial attempt was to create a “superadmin” role.
However, for security reasons, I decided against it. I didn't want a user who could override everything.
As a migration scenario, you could add all current users to all tenants.
There's simply one "first" tenant, and its admins can configure global settings. All other tenants can only access the settings of the tenants they've been invited to.

I really like your updated branding.
It fits in better.

[doncicuto]

Thank you @SteveKueng.... yes I understand your worries about a superadmin... The alternative to assign all current users to existing tenants would work too of course, so let's do that. I'll try to find a way to do that with ent and migrations or as I've done in the past when the console starts for the first time.

Glad you like the changes for the branding view. It's easy to make silly changes when you have something good to work with. I've also changed the reports so they can use the logo you upload:

That logo... :-D

[SteveKueng]

Sounds great!
I never thought about the report. It looks great!
I'm glad you like my work.

[doncicuto]

Hi @SteveKueng, we'll be able to change the default tenant for our account from the My Account page:

I think this is something that the user should be able to change on demand

[SteveKueng]

As I understand it, can a user change their default organization if they have more than one?
I think that makes sense

[doncicuto]

Yes, if the user is a member of several organizations/tenants, the user will be able to select which organization is the one that will be selected automatically when the user logs in

[doncicuto]

Hi @SteveKueng, I was reviewing the roles to describe them in some of the views and for documentation purposes and I wanted to think again the admin role.

There's simply one "first" tenant, and its admins can configure global settings. All other tenants can only access the settings of the tenants they've been invited to.

While I understand the reason to use the main/first tenant approach, I'm not sure if it would be difficult to explain overall. How about keeping your proposed roles: admin, operator, and user but adding a new role admin+ (I can't guess now a better role name) that allows you to be a tenant's admin while being able to manage global settings.

Current OpenUEM users will be migrated to be admin+ for every existing tenant.

I'd like to discuss this a bit with you, you know that yo can easily convince me 😄

Thanks in advance

[SteveKueng]

Hi @doncicuto
Yes, I agree it's not the best solution.
My thoughts were that, "as the MSP, I host OpenUEM. My tenant is the main tenant. I do all the branding and other global stuff. Then I have customers. Each customer has their own environment and can configure some simple things."

The way with an admin or a global configuration admin could also work if you can only change global settings and not view other tenants. Perhaps that would be a better solution.
Another thing to bear in mind is that tenant IDs are currently increasing numbers. It might be better to use random 10-digit numbers.

[doncicuto]

Yes, I'll try to replace the tenant ID, this is some technical debt that I hope I can fix

For the roles, I've post some messages about roles to check what people would like to see

[SteveKueng]

For the tenant ID, I would recommend using a random integer. Leave the existing one as it is.