Get rid of user roles concept for products and repositories

[wkl3nk]

Currently, user roles are defined on these (entity) levels:

• Organization
• Product
• Repository

IMO, this is unnecessarily complicated:

• Create User Management user interfaces on 3 different levels
• Make users understand that actually they need to do the user management on 3 levels
• Understanding some complex "Inheritance" logic will overwhelm users
• Keep all these roles (organization, product, repository) synchronized between ORT Server and Keycloak is more difficult than just a reduced set of roles per organization. Synchronization must take place whenever a organization/product/repository is created or deleted.

Alternative: Only have user roles on Organization level.

Agile approach: I claim, this is good enough for 95% of our future users. Get rid of the roles on product and repository level.

[sschuberth]

What does this mean in practice? That you cannot restrict e.g. product access to only some members of the organization anymore?

[wkl3nk]

Yes, restrictions/authorization are only done on the level of the organization, any additional levels are not required IMO.

One level might be enough because:

• in a company developing software and using OSS, there are only a few dedicated experts that take care for OSS compliance, because they need to have a special skillset and have experience in this domain. There is no need for fine-granular user-management.
• Billing: If the company has several business units, departments, projects, repositories, and they need to have billing on this fine granular level, then the creation of these bills will be very complicated. On the other side, if you just have an organization as a legal entity you have a contract with, then billing is much easier.
• Offboarding: Again, if you have this hierarchy of organization/product/repository, you then also need to have the logic to delete a.) on repository level, b.) on product level and c.) on organization level. If you just have organization level, all you have to do is to dump the organization.

[sschuberth]

there are only a few dedicated experts that take care for OSS compliance

I'm not convinced that having a small number of experts is an argument against having more structure / fine-grained permission control. Also in a small team, only some members may be given access to some (e.g. confidential) projects.

Billing

I don't see how billing relates to fine-granular permission control.

then also need to have the logic to delete a.) on repository level, b.) on product level and c.) on organization level

But that's nothing you should do manually. There should be a "delete user" function for the offboarding use-case that does all of that.

All in all, while I don't have an concrete use-case for roles on product and repository levels right now, my hunch is that we might be obstructing use-cases if we remove this now.

TL;DR I'd keep the feature now that we have it already.

[willebra]

We're a bit lagging in onboarding users which means we have less practical experience.

However, two of our users (separate organizations) both have product/repository level people managing their repos, instead of some OSO people. The organizations don't have OSOs. When we make more products available within these organisations, I expect to have other developers from other products to manage those repos.

Weather they will need to restrict access internally, I don't yet have a case for that. I would expect there to be one. Anyhow I expect there to be quite many persons managing these, as opposed to a few OSO people.

On a more general note, when we sell to SMEs or normal large organizations (as opposed to very large orgs), there will be no OSOs. The typical approach is to "shift left", i.e. have the developers manage this, provide them training, and have certain developers become "ambassadors", an OSO type of expertise. However such ambassadors, or whatever name is used, is always a second or third role alongside other roles the person has.

I would favour to maintain the ability to be nuanced, if needed, with permissions, and take other steps to abstract unnecessary complexity in normal cases.

[Etsija]

IIUC, while we do have roles on those three levels, the roles are however currently inherited top-down, which renders the levels useless as they are now. If a user is given a READ access to an organization, he/she has READ access for all products, and all repositories of the said products, right? At least that's what it was some months ago when I reviewed this last time.

If I am correct with the above, and if we want to manage access rights on all levels, this implicit inheritance of the access rights needs to be changed, in order to for example only give access rights to a user for some products in an organization, or just for some repositories in a product etc.

But maybe this is exactly what you're trying to change now, @wkl3nk, by implementing managing the user rights independently on all levels?

[MarcelBochtler]

• Make users understand that actually they need to do the user management on 3 levels
• Understanding some complex "Inheritance" logic will overwhelm users

I disagree with these statements.
Our users are either software developers or software compliance folk.
GitHub, which both user groups most likely already used, has also 2 levels of user management, as well as permission inheritance.

• Create User Management user interfaces on 3 different levels
• Keep all these roles (organization, product, repository) synchronized between ORT Server and Keycloak is more difficult than just a reduced set of roles per organization. Synchronization must take place whenever a organization/product/repository is created or deleted.

While true, these are implementation details, so users shouldn't care about them and these arguments shouldn't be the main motivator for designing a permission system.

Agile approach: I claim, this is good enough for 95% of our future users. Get rid of the roles on product and repository level.

Changing a permission system at a later point seems nearly impossible.