> Markdown version of https://docs.laavat.io/appendixes/permissions/ from the LAAVAT PKI and Signing Platform documentation. All pages: https://docs.laavat.io/llms.txt

# Permissions Reference

[Groups Management](https://docs.laavat.io/usage/adminguide/groups/) describes how to create and configure the platform's
groups. This page answers the next question: **which group does a person need to be in
so they can do their job?**

Every group named here holds Entra ID (or Google Cloud) group IDs. Adding someone to one
of those directory groups is what grants them access — there is no separate user
management inside LAAVAT.

## Four rules worth reading first

These are the parts of the model people most often get wrong.

> **Warning: Membership of **any** listed group grants access — never all of them**
> Where a task lists two or more groups, being in one of them is enough. No operation
> requires a person to be in two groups at the same time. If you add someone to
> `productReaderGroups` to let them view products, they can view products — regardless
> of what else they are or are not a member of.

> **Warning: `initialReaderGroups` grants nothing**
> It can be configured, and it looks like it should provide read access to system
> configuration, but it is never consulted. Read access to system configuration comes
> from `initialWriterGroups` or `initialApproverGroups`. Do not rely on
> `initialReaderGroups` to grant anything.

> **Note: `blanketGroups` is auto-approval, not access**
> A product operation's `blanketGroups` does not grant access to any endpoint. It is
> checked only *after* access has already been granted, and its effect is that the
> request is approved automatically instead of waiting for an approver. To let someone
> submit a request at all, put them in the operation's `allowedGroups`.

> **Note: Product approvals are scoped by product type**
> Members of `caApprovalGroups` may approve only products of type **CA**. Members of
> `productApprovalGroups` may approve only products of type **RnD** and **Production**.
> Both groups can call the same approval endpoints, but each sees and acts on only its
> own product types.

## Configuration groups

These are set with a group configuration request — see [Groups Management](https://docs.laavat.io/usage/adminguide/groups/).

### Products

| Group | What a member can do |
| --- | --- |
| `productReaderGroups` | View products and product details, product templates, product change requests, master key requests, image signing requests and audit trails. Read-only — cannot create, change or approve anything. |
| `productListReaderGroups` | View the product list, the product templates and the image signing request list, but not individual product details. Use this for people who need an overview without access to product internals. |
| `productWriterGroups` | Create and delete products, create and modify product templates, raise product change requests and master key requests, and read audit trails. Cannot approve their own requests. |
| `productApprovalGroups` | Approve product creation, product change requests and master key requests, and delete products. Approves only **RnD** and **Production** products — see the product type rule above. |

### CA and PKI

| Group | What a member can do |
| --- | --- |
| `caReaderGroups` | View CAs, root CAs and the CA hierarchy, certificate profiles, issued certificates, CRLs and PKI change requests. Also sees products, because a product carries its CA configuration. Read-only. |
| `caWriterGroups` | Create and delete certificate profiles, modify a CA, generate CRLs, raise PKI change requests, and create products. Cannot approve. |
| `caApprovalGroups` | Approve PKI change requests, and approve products of type **CA**. |

### Revocation

Revocation is deliberately separate from the CA groups, so that the ability to revoke a
certificate can be given to a different set of people from the ability to issue one.

| Group | What a member can do |
| --- | --- |
| `revocationWriterGroups` | Request a certificate revocation, and view certificates and existing revocation requests. Cannot approve a revocation. |
| `revocationApprovalGroups` | Approve revocation requests, and view certificates and revocation requests. |

### Client and escrow registration

Escrow is superseded on the platform by the export paths described in
[key custody and export](https://docs.laavat.io/security/#key-custody-and-export). The two escrow
groups below still exist and still gate the escrow registration endpoints, but escrow is
not a key-recovery route you should plan around.

| Group | What a member can do |
| --- | --- |
| `registerClientGroups` | Register a client, raise a client change request, view registered clients, and delete a client. |
| `registerClientApprovalGroups` | Approve client registrations and client change requests, view registered clients, and delete a client. |
| `registerEscrowGroups` | Register an escrow and view registered escrows. |
| `registerEscrowApprovalGroups` | Approve escrow registrations and view registered escrows. |

## Bootstrap groups

These two are set at installation time, not through a configuration request, and they
govern the system configuration itself — including the configuration groups above. See
[Initial Groups](https://docs.laavat.io/getting-started/onboarding/initialgroups/).

| Group | What a member can do |
| --- | --- |
| `initialWriterGroups` | Raise system configuration requests: group configuration, provisioning configuration, EST service configuration, truststore changes and IdP secret rotation. Also read all of those. |
| `initialApproverGroups` | Approve all of the above, and read all of the same configuration. |

Because these groups control who controls everything else, keep them small and keep the
two memberships separate — a person who can both raise and approve a configuration change
can grant themselves any other permission on this page.

## Per-operation groups

Products define signing and certificate operations, and each operation carries its own
approval rule. These groups are set per operation in the product definition, not in the
system configuration, so they differ from product to product.

| Group | What a member can do |
| --- | --- |
| `allowedGroups` | Submit requests for that operation — sign an image, request a certificate — and read back their own requests. |
| `approvalGroups` | Approve requests for that operation, and read requests awaiting approval. |
| `blanketGroups` | Nothing on its own. Requests from a member are auto-approved rather than queued. See the rule above. |

## Task lookup

| To do this | A person needs to be in |
| --- | --- |
| Browse the product list | `productListReaderGroups` or `productReaderGroups` |
| View a product's details | `productReaderGroups` or `caReaderGroups` |
| Create a product | `productWriterGroups` or `caWriterGroups` |
| Approve a new RnD or Production product | `productApprovalGroups` |
| Approve a new CA product | `caApprovalGroups` |
| Delete a product | `productWriterGroups` or `productApprovalGroups` |
| Raise a product change request | `productWriterGroups` |
| Approve a product change request | `productApprovalGroups` |
| Read audit trails | `productReaderGroups` or `productWriterGroups` |
| Request a master key | `productWriterGroups` |
| Approve a master key request | `productApprovalGroups` |
| View CAs, profiles, certificates and CRLs | `caReaderGroups` |
| Create or delete a certificate profile | `caWriterGroups` |
| Modify a CA or generate a CRL | `caWriterGroups` |
| Raise a PKI change request | `caWriterGroups` |
| Approve a PKI change request | `caApprovalGroups` |
| Request a certificate revocation | `revocationWriterGroups` |
| Approve a revocation | `revocationApprovalGroups` |
| Register a client | `registerClientGroups` |
| Approve a client registration | `registerClientApprovalGroups` |
| Register an escrow | `registerEscrowGroups` |
| Approve an escrow registration | `registerEscrowApprovalGroups` |
| Submit a signing or certificate request | the operation's `allowedGroups` |
| Approve a signing or certificate request | the operation's `approvalGroups` |
| Change the configuration groups themselves | `initialWriterGroups` to request, `initialApproverGroups` to approve |
| Rotate the IdP secret | `initialWriterGroups` to request, `initialApproverGroups` to approve |
| Change the truststore | `initialWriterGroups` to request, `initialApproverGroups` to approve |
| Configure the EST service or provisioning | `initialWriterGroups` to request, `initialApproverGroups` to approve |

## Endpoints with no group check

A few endpoints do not use group membership at all:

- `/login`, `/logingui`, `/auth/callback`, `/auth/callbackgui` and `/auth/refreshtoken`
  are part of the authentication flow itself.
- `/health`, `/approvals` and `/user/capabilities` accept any valid token. `/approvals`
  returns counts only, and `/user/capabilities` returns what the calling user may do.
- The `/mtls/*` routes authenticate with a client certificate instead of a token. Access
  depends on the certificate being registered to the product with a suitable role, not on
  directory group membership.
- The distribution endpoints for product secrets, fusemaps and wrapped keys require a
  registered and approved escrow or client, again not a group.

## Checking a specific endpoint

The per-endpoint rule is published with each operation in the
[Interactive Documentation](https://docs.laavat.io/api/swagger/), under **Access/Roles**. That section
names the exact groups the endpoint accepts and where each is configured.

To see what your own account can currently do, call `GET /user/capabilities` — the GUI
uses the same call to decide which menu items to show.