Custom RBAC: Creating a "Read Only" custom role (RBAC purposes) in an Internal OpenVSX deployment

[devex-luis]

Hi - Our team just completed the internal deployment of OpenVSX. During some internal testing, we realized that there are only two roles that ship out of box with OpenVSX (e.g., Administrator and Publisher, I believe). However, internally, we want to allow our users to just browse the marketplace, after authenticating with our own internal auth provider.

Would this require simply just inserting a new role in the user table as "Browse" and not assigning a user token to it? I'm happy to provide more details on what the experience should look like.

Thanks in advance.

[netomi]

The registry right now is designed around being open. If login providers are available and setup anybody that logged in and created an account thus with the registry, can publish.

There are 2 special roles that can be assigned to users:

• admin
• privileged

they have additional permissions, but any other user can publish to namespaces that he/she has access to.

You can not setup a login provider right now to prevent users from publishing extensions, but then you would have to setup an admin user manually to publish via a token on the cli.

Changing that to only allow users to publish with a specific role would require a lot of changes afaict.

[devex-luis]

Thanks @netomi for getting back to me. For this point:

The registry right now is designed around being open.

My question was within the context of an internal deployment of OpenVSX. Are you saying that even with an internal (corporate) deployment of OpenVSX, anyone can still publish, by design?

The publishing operations are already handled by the (internal) catalog maintainers, not by the individual publishers of each extension.

[netomi]

When you do an internal deployment why do you need an auth provider? Users will usually interface with the registry via its vscode api from their IDEs which anyway has no authentication.

The authentication is just needed to be able to access the admin interface and publish extensions via the web UI. However, when you setup an admin / privileged user in the DB and create a token for them, you can just publish via the ovsx command line tool and prevent that users can login and publish extensions.

[devex-luis]

Part of the core experience (end to end) is to allow internal consumers to browse (visually), the catalog in addition to using the code editor. The default authentication provider is not an option that we can use at this time.

[netomi]

but there is no need to configure an authentication provider afaict

[devex-luis]

@netomi Thanks again for your prompt response! I understand that configuring an alternative auth provider is optional. However, taking this approach is a business requirement.

For the second component of my question (admin, privileged), can those two roles be customized to reduce scope? Or can we introduce a new role (e.g., Browse) with none of the permissions assigned to the admin role or the privileged role?

[netomi]

to browse the registry you do not need to authenticate at all thus my question why you even need an authentication provider.