Access Management

Supply chain security documents are the what of BOMnipotent, users are the who. Unless you explicitly state otherwise, the hosted documents are only visible to those user accounts you grant access to.

BOMnipotent uses role-based access control (RBAC): Users have roles, and roles have permissions . After setup, BOMnipotent contains a few default roles. These are sufficient for managing the server, but to start accepting user request, you will probably want to create at least one new role.

Once that is done, a typical workflow for introducing a new user to your BOMnipotent system is as follows:

  1. A new user requests access to your server. During this step, BOMnipotent Client sends a public key associated with the account to your server, where it is stored and marked as “requested”.
  2. You approve the request. The new user account is now accepted as valid, but it does not have any permissions yet.
  3. You assign one or more roles to the new user account.

Subsections of Access Management

Permissions

In BOMnipotent, permissions are not directly associated with user accounts, but rather with roles. The section about role management covers how this association is managed, and the section about role assignment explains how roles (and thus ultimately permissions) are assigned to users.

The server has several permissions embedded in its code, some of which are hardcoded, some of which are configurable, and all of which are explained here. To learn how to actually create a permission associated with a role, please refer to the section dedicated to exactly that topic.

The permissions can mentally be split into permissions associated with consumers , managers , and some special tasks reserved for admins.

Consumer Permissions

Your customers are typically associated with one or more of your products. They will want to view all types of documents and information for that particular product, but they are not automatically entitled to information about other products.

PRODUCT_ACCESS

A permission with the value “PRODUCT_ACCESS(<PRODUCT>)” grants read permissions to any document associated with “<PRODUCT>”. This includes any BOM for that product, any vulnerabilities associated with these BOMs, and any CSAF documents covering this product.

For example, a role with the “PRODUCT_ACCESS(BOMnipotent)” could view (and only view) all documents associated with BOMnipotent.

It is possible to use the asterisk operator “*” to glob product names. In that case, the asterisk matches an arbitrary number of symbols. For example, the permission “PRODUCT_ACCESS(BOM*ent)” would match “BOMnipotent” as well as the (fictional) products “BOMent” and “BOM-burárum-ent”, but not “BOMtastic” (because the latter does not end on “ent”).

Consequently, “PRODUCT_ACCESS(*)” allows the viewing of all documents.

Manager Permissions

For managers of documents, the situation is usually reversed: They need the permission to not only view but also modify the contents in the database. Their scope is typically not restricted to a specific product, but instead to a specific type of document. This is why the segregation of manager permissions takes another perspective.

BOM_MANAGEMENT

This permission allows the uploading, modifying and deleting of Bills of Materials (BOMs). It also automatically grants permission to view all hosted BOMs.

VULN_MANAGEMENT

This permission allows to update and view the list of vulnerabilities associated with any BOM.

CSAF_MANAGEMENT

Unsurprisingly, this permission allows the uploading, modifying and deleting of Common Security Advisory Format (CSAF) documents. It also automatically grants view permissions to all hosted CSAF documents.

ROLE_MANAGEMENT

With this permission, a user can modify the permissions of roles, which can have far reaching consequences, because the changes potentially affect many users.

USER_MANAGEMENT

This permission is required to approve, deny or view users, or to individually assign roles to them.

Special Admin permissions

BOMnipotent knows one hardcoded special role called “admin”. This role always has all permissions that can be given to users. Additionally, there are some tasks that can only be done by a user with the admin role:

Role Management

BOMnipotent uses a role-based access model (RBAC), in which users are associated with roles, and roles with permissions. While permissions are largely hardcoded into BOMnipotent, roles can be managed (almost) freely. This section explains how to do that.

To modify or even view roles and their permissions, your user account needs the ROLE_MANAGEMENT permission.

Default Roles

When you spin up your BOMnipotent Server for the first time, it creates several colourfully named default roles in the database:

You can modify or delete these roles at will, they are merely suggestions.

If you do not like these roles, use the following calls to delete them:

bomnipotent_client role-permission remove bom_manager BOM_MANAGEMENT;
bomnipotent_client role-permission remove csaf_manager CSAF_MANAGEMENT;
bomnipotent_client role-permission remove role_manager ROLE_MANAGEMENT;
bomnipotent_client role-permission remove user_manager USER_MANAGEMENT;
bomnipotent_client role-permission remove vuln_manager VULN_MANAGEMENT;

Admin Role

There is a special role called “admin”, which is not listed among the other roles. The reason is that it is not part of the database, but of the BOMnipotent code itself. As such, it cannot be modified.

​
bomnipotent_client role-permission remove admin BOM_MANAGEMENT
bomnipotent_client role-permission add admin "PRODUCT_ACCESS(BOMnipotent)"
​
[ERROR] Received response:
422 Unprocessable Entity
Cannot modify admin role permissions

The admin role has all permissions that can be granted, and then some more .

Listing

To list all roles and their associated permissions, call:

bomnipotent_client role-permission list
​
╭──────────────┬─────────────────┬───────────────────────────╮
│ Role         │ Permission      │ Last Updated              │
├──────────────┼─────────────────┼───────────────────────────┤
│ bom_manager  │ BOM_MANAGEMENT  │ 2025-03-20 10:38:27.29648 │
│              │                 │ 0 UTC                     │
│ csaf_manager │ CSAF_MANAGEMENT │ 2025-03-20 10:38:27.29695 │
│              │                 │ 2 UTC                     │
│ role_manager │ ROLE_MANAGEMENT │ 2025-03-20 10:38:27.29621 │
│              │                 │ 3 UTC                     │
│ user_manager │ USER_MANAGEMENT │ 2025-03-20 10:38:27.29562 │
│              │                 │ 0 UTC                     │
│ vuln_manager │ VULN_MANAGEMENT │ 2025-03-20 10:38:27.29671 │
│              │                 │ 9 UTC                     │
╰──────────────┴─────────────────┴───────────────────────────╯

Adding

Because roles without permissions are meaningless, the two always come in pairs. There is no dedicated mechanism to create a new role: rather, you add a permission to a role, and henceforth it exists.

The syntax to add a permission to a role is

bomnipotent_client role-permission add <ROLE> <PERMISSION>
​
[INFO] Added permission BOM_MANAGEMENT to role

You could for example unify several permissions into the roles “doc_manager” and “access_manager”:

bomnipotent_client role-permission add doc_manager BOM_MANAGEMENT;
bomnipotent_client role-permission add doc_manager CSAF_MANAGEMENT;
bomnipotent_client role-permission add doc_manager VULN_MANAGEMENT;
bomnipotent_client role-permission add access_manager ROLE_MANAGEMENT;
bomnipotent_client role-permission add access_manager USER_MANAGEMENT;

If you have removed the default roles as described above, this leaves you with:

bomnipotent_client role-permission list
​
╭────────────────┬─────────────────┬───────────────────────────╮
│ Role           │ Permission      │ Last Updated              │
├────────────────┼─────────────────┼───────────────────────────┤
│ access_manager │ ROLE_MANAGEMENT │ 2025-03-20 11:05:42.06443 │
│                │                 │ 7 UTC                     │
│ access_manager │ USER_MANAGEMENT │ 2025-03-20 11:04:57.51274 │
│                │                 │ 7 UTC                     │
│ doc_manager    │ BOM_MANAGEMENT  │ 2025-03-20 11:05:55.15986 │
│                │                 │ 0 UTC                     │
│ doc_manager    │ CSAF_MANAGEMENT │ 2025-03-20 11:05:50.92466 │
│                │                 │ 9 UTC                     │
│ doc_manager    │ VULN_MANAGEMENT │ 2025-03-20 11:05:47.35620 │
│                │                 │ 9 UTC                     │
╰────────────────┴─────────────────┴───────────────────────────╯

If the permission you want to add does not exist or is malformed, you will receive an error:

bomnipotent_client role-permission add clam_manager CLAM_MANAGEMENT
​
[ERROR] Received response:
422 Unprocessable Entity
Failed to parse permission: Invalid UserPermission string: CLAM_MANAGEMENT

Removing

To remove a permission from a role, simply call:

bomnipotent_client role-permission remove <ROLE> <PERMISSION>
​
[INFO] Removed permission VULN_MANAGEMENT from role vuln_manager

Once you have removed the last role from a permission, that role does no longer exist.

To prevent oopsie-moments, BOMnipotent does not support deleting whole batches of role-permissions.

User Management

The first step when creating a new user is to request a new account. This step is described elsewhere , because it is relevant for managers and consumers alike.

From BOMnipotent’s point of view, a user is associated with a unique email address, which is used as an identifier, and a public key, which is used for authentication. This is all the data sent during the creation of a new user account.

After a new account has been requested, it is up to a user manager to approve or deny the request.

For most user interactions, including listing, you need the USER_MANAGEMENT permission.

Listing

To list all users in your database, call

bomnipotent_client user list
​
╭────────────────────┬───────────┬─────────────────────────┬─────────────────────────╮
│ User Email         │ Status    │ Expires                 │ Last Updated            │
├────────────────────┼───────────┼─────────────────────────┼─────────────────────────┤
│ admin@wwh-soft.com │ APPROVED  │ 2026-03-23 04:51:26 UTC │ 2025-03-22 04:51:26 UTC │
│ info@wildeheide.de │ REQUESTED │ 2026-03-23 03:52:21 UTC │ 2025-03-22 03:52:21 UTC │
╰────────────────────┴───────────┴─────────────────────────┴─────────────────────────╯

You can see the email addresses of the users and their stati.

A user that does not have the status APPROVED has no special permissions, no matter which roles they have.

An expiration date is also associated with each user, which is the point in time at which the public key is considered invalid and has to be renewed. The period for which a key is considered valid can be freely configured in the server config.

Approval or Denial

If you were expecting the user request, you can approve it via

bomnipotent_client user approve <EMAIL>
​
[INFO] Changed status of info@wildeheide.de to APPROVED

Analogously, you can decide agains allowing this user any special access:

bomnipotent_client user deny <EMAIL>
​
[INFO] Changed status of info@wildeheide.de to DENIED

It is possible to deny a user that has already been approved, effectively revoking the account.

Deleting

If you want to get rid of a user account alltogether, call

bomnipotent_client user remove <EMAIL>
​
[INFO] Deleted user info@wildeheide.de

Role Assignment

Roles are what connects users to permissions. Adding or removing roles to and from users indirectly controls to what extend users can interact with your BOMnipotent Server instance.

For your convenience, several default roles are created upon starting BOMnipotent Server for the first time. In addition, BOMnipotent knows of the admin role , which receives some special treatment.

To modify or even view user roles, your user account needs the USER_MANAGEMENT permission.

Listing

To list all roles of all users, call

bomnipotent_client user-role list
​
╭──────────────────┬─────────────┬───────────────────────────╮
│ User Email       │ User Role   │ Last Updated              │
├──────────────────┼─────────────┼───────────────────────────┤
│ info@quantumwire │ bom_manager │ 2025-03-22 04:27:33.71579 │
│                  │             │ 7 UTC                     │
│ info@wildeheide  │ bom_manager │ 2025-03-22 04:26:08.83708 │
│                  │             │ 3 UTC                     │
╰──────────────────┴─────────────┴───────────────────────────╯

Adding

To add a new role to a user, call

bomnipotent_client user-role add <EMAIL> <ROLE>
​
[INFO] Added role to user

The user account needs to exist on the server at this point, the role does not.

Only users with the admin role can add the admin role to other users.

Removing

To remove a role from a user, call

bomnipotent_client user-role remove <EMAIL> <ROLE>
​
[INFO] Removed role bom_manager from user info@wildeheide

This will show an error if either does not exist:

​
[ERROR] Received response:
404 Not Found
User with email info@wildeheide does not have role bom_manager

Only users with the admin role can remove the admin role from other users.