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

# System Configuration

## Overview

System configuration defines the **security groups** that control access to LAAVAT Platform operations. Groups are organized by function, and each group grants its members specific permissions within the platform. This page allows administrators to manage the mapping between identity provider groups and platform roles.

Security groups are the primary mechanism for role-based access control (RBAC) in the LAAVAT Platform. By associating identity provider group identifiers with platform permission categories, administrators can ensure that only authorized users have access to sensitive operations such as CA management, certificate revocation, and client registration.

> **Tip: Prerequisites**
> Before configuring security groups, ensure that your organization's identity provider (Microsoft Entra ID or Google Cloud) has been integrated during onboarding and that the required groups have been created in the identity provider.

---

## Security Groups

Each security group is identified by a **UUID** obtained from your identity provider. The LAAVAT Platform supports the following identity providers:

| Identity Provider | Group Identifier Format |
|-------------------|------------------------|
| **Microsoft Entra ID** (formerly Azure AD) | Object ID (UUID) of the Entra ID group |
| **Google Cloud** | Group ID (UUID) from Google Cloud Identity |

### How Groups Work

When a user authenticates with the LAAVAT Platform, their identity token includes the groups they belong to. The platform matches these group identifiers against the configured security groups to determine which operations the user is authorized to perform.

> **Warning: Group UUID accuracy**
> Ensure that the UUIDs entered match exactly with the group identifiers in your identity provider. An incorrect UUID will result in users being unable to access the intended operations, and no error will be displayed during authentication -- permissions will simply not be granted.

### Configuring a Group

Existing configuration cannot be modified directly. To change a security group, a new configuration must be created and submitted for approval. Once approved, it is taken into use.

1. Navigate to **Administration > System Configuration**.
2. Select **Add new configuration**.
3. Enter the **UUIDs** of the group identifiers in the relevant fields.
4. Submit the new configuration for approval.
5. Once an approver has approved the request, the configuration is taken into use.

Each group category accepts **one or more UUIDs**. Multiple groups can be assigned to the same permission category.

---

## Group Categories

The LAAVAT Platform organizes security groups into functional categories. Each category controls access to a specific set of operations.

### Product Groups

| Group | Permission | Description |
|-------|-----------|-------------|
| **Product Writer** | Full access to product operations | Members can create and manage products. |
| **Product Reader** | Read-only access to product details | Members can view detailed product information. |
| **Product List Reader** | Read-only access to product list | Members can view the list of products. |
| **Product Approval** | Approve product creation | Members can approve product creation requests. |

### CA Groups

| Group | Permission | Description |
|-------|-----------|-------------|
| **CA Read** | Read-only access to Certificate Authority information | Members can view CA details, certificates, and status but cannot make changes. |
| **CA Write** | Full access to Certificate Authority operations | Members can create, modify, and manage CAs and their certificates. Includes all CA Read permissions. |
| **CA Approval** | Approve CA operations | Members can approve CA-related requests. |

> **Tip: Separation of duties**
> For environments requiring strict separation of duties, assign CA Read and CA Write to different groups. This ensures that personnel who audit CA configurations are distinct from those who manage them.

### Register Client Groups

| Group | Permission | Description |
|-------|-----------|-------------|
| **Register Client** | Access to client registration operations | Members can register new clients, modify existing registrations, and delete client entries. |
| **Register Client Approval** | Approve client registrations | Members can approve client registration requests. |

### Revocation Groups

| Group | Permission | Description |
|-------|-----------|-------------|
| **Revocation Writer** | Full access to revocation operations | Members can revoke and unrevoke certificates and view revocation information. |
| **Revocation Approval** | Approve revocation requests | Members can approve certificate revocation requests. |

---

## Best Practices

> **Warning: Principle of least privilege**
> Always assign the minimum set of permissions required for each role. Use **Read** groups for users who only need visibility, and reserve **Write** groups for users who actively manage resources.

- **Audit group assignments regularly.** Ensure that group memberships in your identity provider reflect current organizational roles.
- **Document group-to-UUID mappings.** Maintain an internal record of which identity provider groups map to which platform permissions.
- **Test configuration changes.** After a new configuration is approved and taken into use, verify access by having a member of the affected group log in and confirm the expected permissions.
- **Use separate groups per category.** Avoid reusing the same identity provider group across multiple categories unless the same team genuinely needs all those permissions.