> For the complete documentation index, see [llms.txt](https://docs.catalyx.solutions/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.catalyx.solutions/catalyx-blockchain-manager/canton-network/version-2.0/validator-management/users-and-rights.md).

# Users & Rights

"User" means three different things in a CAT-BM deployment, and confusing them is the most common source of "I created a user but they can't log in".

<table><thead><tr><th width="220">Kind</th><th width="230">Lives in</th><th>Lets someone…</th></tr></thead><tbody><tr><td><strong>Identity provider user</strong></td><td>Your OIDC provider — Keycloak, Okta, Entra ID, and so on</td><td>Authenticate. This is the actual account and credential.</td></tr><tr><td><strong>Ledger user</strong></td><td>The Canton participant node</td><td>Act on the ledger, with rights over specific parties.</td></tr><tr><td><strong>Wallet user</strong></td><td>The validator app</td><td>Sign in to the Canton Wallet UI.</td></tr></tbody></table>

{% hint style="warning" %}
CAT-BM creates ledger users and wallet users. It does **not** create identity provider accounts. The identity must already exist in your OIDC provider, and the username must match.
{% endhint %}

***

## Onboarding a person end to end

{% stepper %}
{% step %}
**Create the account in your identity provider**

Create the user in the realm your validator authenticates against, and give them a credential. Note the username exactly — you will reuse it.
{% endstep %}

{% step %}
**Allocate a party, if they need one**

On the validator's **Parties** tab, use **Allocate Party** with a short hint. The participant generates the full party ID.

If the person should hold their own signing key rather than trusting the participant, onboard them as an [external party](/catalyx-blockchain-manager/canton-network/version-2.0/validator-management/external-and-multi-host-parties.md) instead.
{% endstep %}

{% step %}
**Create the ledger user**

On the **Users** tab, **Create User**. Set the **User ID** to match the identity provider username, set the **Primary party** to the party from the previous step, and grant **Can act as** that party.
{% endstep %}

{% step %}
**Onboard the wallet user, if they need the Wallet UI**

On the **Wallet Users** tab, **Add Wallet User** with the same username.
{% endstep %}

{% step %}
**Hand over the URL**

Give them the Wallet UI address from the validator's **Endpoints** tab.
{% endstep %}
{% endstepper %}

***

## Ledger rights

A ledger user's rights fall into two groups, and the distinction matters a great deal.

### Party-scoped rights

These name specific parties, and are what you should be using in almost every case.

<table><thead><tr><th width="220">Right</th><th>Grants</th></tr></thead><tbody><tr><td><strong>Can act as</strong></td><td>Submitting commands on behalf of the named parties — creating and exercising contracts as them.</td></tr><tr><td><strong>Can read as</strong></td><td>Reading the named parties' contracts and transaction history.</td></tr><tr><td><strong>Can execute as</strong></td><td>Executing on behalf of the named parties.</td></tr></tbody></table>

### Participant-wide rights

These are not scoped to any party.

<table><thead><tr><th width="270">Right</th><th>Grants</th></tr></thead><tbody><tr><td><strong>Participant admin</strong></td><td>Full administrative control of the participant node.</td></tr><tr><td><strong>Identity provider admin</strong></td><td>Administration of the participant's identity provider configuration.</td></tr><tr><td><strong>Can read as any party</strong></td><td>Read access to <em>every</em> party's data on the node.</td></tr><tr><td><strong>Can execute as any party</strong></td><td>Execution on behalf of any party on the node.</td></tr></tbody></table>

{% hint style="danger" %}
`Can read as any party` defeats Canton's per-party data privacy on that participant, and `Participant admin` grants everything. Reserve both for platform service accounts, never for individual users or per-tenant applications.
{% endhint %}

### Editing rights is a replacement

{% hint style="warning" %}
Saving the rights editor sets the user's **complete** rights — anything you removed is revoked. Always open the editor from the user's row or rights drawer, so it starts pre-populated with the current rights.
{% endhint %}

## Deactivating a user

In edit mode, tick **Deactivated** — *user cannot authenticate to the ledger*. This is preferable to deleting rights: it blocks access immediately while preserving the user's configuration, so it is reversible and leaves an audit trail.

## Annotations

Edit mode also allows arbitrary key/value **annotations** on a ledger user. These are metadata for your own use — a tenant ID, an owning team, a ticket reference. They are not interpreted by CatalyX or Canton.

## Related

* [Users & Wallet Users](/catalyx-blockchain-manager/canton-network/version-2.0/console-guide-canton/validators/users-and-wallet-users.md) — the console screens
* [Identity Provider Configuration](/catalyx-blockchain-manager/canton-network/version-2.0/installation-instructions-canton/identity-provider-configuration.md) — how a validator authenticates
* [Security & Privacy](/catalyx-blockchain-manager/canton-network/version-2.0/architecture/security-and-privacy.md) — the platform's access control model


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.catalyx.solutions/catalyx-blockchain-manager/canton-network/version-2.0/validator-management/users-and-rights.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.