> For the complete documentation index, see [llms.txt](https://docs.opendatadiscovery.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.opendatadiscovery.org/configuration-and-deployment/enable-security/authorization/user-owner-association.md).

# User-owner association

User-owner association links a signed-in user to an [owner](/configuration-and-deployment/enable-security/authorization/owners.md) entity. Without an association, the user cannot manage data entities and cannot be granted ownership-scoped permissions through an owner's [Role](/configuration-and-deployment/enable-security/authorization/roles.md) bundles.

The platform supports three write-paths to create the binding:

* **Self-request, then admin approves** — a regular user submits a request from the home page; an administrator approves it on Management → Associations → New requests.
* **Self-request with auto-approve** — a user holding the `DIRECT_OWNER_SYNC` permission submits the same form; the platform auto-approves on the spot.
* **Admin direct-bind** — an administrator holding the `OWNER_RELATION_MANAGE` permission creates the binding directly from Management → Associations using the **Create association** button.

{% hint style="info" %}
User-owner association is a one-to-one relation. A user can be associated with only one owner, and an owner can be associated with only one user at a time.
{% endhint %}

## For regular users

After signing in, scroll to the bottom of the [Catalog Overview](/features/data-discovery/catalog-overview.md) home page. The **Owner association** widget appears inline as the last block on the page — it is not a modal dialog and has no overlay.

The widget shows a single input — **Owner name** — and a **Send a request** button.

### Choosing an owner name

Type to search the existing owner directory. As you type, the platform searches the catalog; suggested matches against your username appear under **Maybe it's you**.

If no existing owner matches the name you typed, **the platform creates a new owner with exactly that name when you submit**. This is by design — operators want users to be able to bind to a brand-new owner — but it also means typos and casing variants ("John Smith" vs "john smith" vs "John Smith") accumulate in the owner directory.

**Recommendation for operators:** pick a stable owner-name convention for your deployment (case, whitespace, trailing characters) and communicate it to new users. The owner directory can be cleaned up by an administrator from Management → Owners; an administrator with the `OWNER_RELATION_MANAGE` permission can also remove individual bindings via Management → Associations → Active associations (see below).

### After you submit

When you press **Send a request**, your request appears on Management → Associations → **New requests** for an administrator to review.

While your request is pending, the home-page widget is replaced with a **Request is being checked** message.

### If your request is declined

If an administrator declines your request, the next time you reach the home page you see a banner above a fresh request form. You can dismiss the banner with the **X** button, but **the dismissal does not persist** — refreshing the page or signing in again brings the banner back until you submit another request.

There is no per-decline-reason surface; the message is the same regardless of why the request was declined. If you need the reason, ask the administrator directly.

### Changing or removing your association

Once your association is approved, you have no self-service path to change or remove it. The home-page widget now shows your owner's entities and does not offer a **Disassociate** or **Switch owner** action.

To switch to a different owner, or to remove your binding entirely, **ask an administrator with the `OWNER_RELATION_MANAGE` permission to remove the binding** via Management → Associations → Active associations (see [Removing an existing binding](#removing-an-existing-binding-active-associations-tab) below). After removal, the request form reappears on your next sign-in.

## For administrators

The administrative workflow lives at [**Management → Associations**](/features/management.md) — a top-nav tab with three sub-tabs: **New requests** (incoming pending requests), **Active associations** (existing bindings), and **History** (resolved requests audit).

The **Associations** tab is hidden from operators who do not hold the `OWNER_ASSOCIATION_MANAGE` permission.

### Approving incoming requests (New requests tab)

The **New requests** sub-tab lists every open pending request, one row per user. Each row shows:

| Column         | Source                                      |
| -------------- | ------------------------------------------- |
| **User name**  | The signed-in user's OIDC / LDAP username   |
| **Owner name** | The owner the user requested                |
| **Role**       | Owner roles attached to that owner (if any) |
| **Provider**   | The auth provider the user signed in with   |

Per-row **Accept** and **Reject** buttons each open a confirmation dialog before writing. Accept records the request as APPROVED and writes the user-owner binding; Reject records it as DECLINED. Both actions are written to the audit channel surfaced on the **History** sub-tab and require the `OWNER_ASSOCIATION_MANAGE` permission.

### Creating a binding directly (Create association)

In the **Associations** tab header, operators holding the `OWNER_RELATION_MANAGE` permission see a **Create association** button. (The button is hidden for operators without the permission.)

Clicking it opens a modal form with three required fields:

| Field        | Notes                                                                                                                                                                                                                                     |
| ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Owner**    | Pick from the existing owner directory — this path does not create new owners.                                                                                                                                                            |
| **User**     | Free-text — type the OIDC / LDAP username verbatim. The platform does not verify the username exists in your identity provider; an incorrect username is accepted at the API level and silently produces a binding nobody can sign in to. |
| **Provider** | Pick from the list of providers active on this deployment.                                                                                                                                                                                |

On submit, the platform writes the binding directly — there is no intermediate "pending" state and no second-administrator approval. The action is gated by the `OWNER_RELATION_MANAGE` permission (not `OWNER_ASSOCIATION_MANAGE`).

{% hint style="warning" %}
**Provider is not always a reliable discriminator.** The Provider value you pick here (and the Provider column shown across the New requests, Active associations, and History tabs) does not isolate a binding to one sign-in method in every deployment. Both `LOGIN_FORM` and `LDAP` logins are stored with an empty provider, so a binding made for one is matched for the other when the username is the same. If your deployment has run more than one auth mode over its lifetime, read the [cross-mode user-name collision](/configuration-and-deployment/enable-security/authentication/login-form.md#cross-mode-user-name-collision-activity-feed-read-paths) caveat before relying on Provider to keep two same-named users apart.
{% endhint %}

### Removing an existing binding (Active associations tab)

The **Active associations** sub-tab lists every approved binding — one row per user-owner pair, with the columns from the New requests tab plus **Resolved by** (the administrator who approved or created the binding) and **Resolved at**.

Each row has a **Remove** button that opens a confirmation dialog reading *"User X will stop being associated with owner Y."* On confirm, the binding is deleted at the platform tier.

**Remove is the only operator-side path to undo any binding** — including bindings created through the auto-approve short-circuit (`DIRECT_OWNER_SYNC`) and through the admin **Create association** button.

The backend permission gate on this endpoint is `OWNER_RELATION_MANAGE`. On the current UI, the Remove button is enabled when the operator holds `OWNER_ASSOCIATION_MANAGE` — so an operator who holds only `OWNER_RELATION_MANAGE` may see the button but the backend will accept the call, and an operator who holds only `OWNER_ASSOCIATION_MANAGE` may click the button only to have the backend reject it. Until that inconsistency is resolved, grant both permissions to operators who need direct-bind authority.

#### After you remove an association

The confirmation dialog describes the local effect only. The wider consequences for the affected user:

* Their **My objects** view in [Activity Feed](/features/active-platform-features/activity-feed.md) goes empty.
* Their **My** view in [Alerting](/features/active-platform-features/alerting.md) goes empty.
* Any ownership-scoped permissions granted through the owner's [Role](/configuration-and-deployment/enable-security/authorization/roles.md) bundles are no longer applied on their next request.

The user is not notified by the platform. If they reach out about empty dashboards or missing access shortly after, an unbind is the likely cause.

### Auditing past association requests (History tab)

The **History** sub-tab lists resolved requests — both APPROVED and DECLINED — in reverse chronological order. The columns are User name, Owner name, Role, Provider, Resolved by, Status, Resolved at.

This sub-tab is read-only. The underlying activity stream is reachable to any signed-in user — operators auditing who-approved-what should be aware that the resolved-association log is part of the platform's read-collaborative posture on Management surfaces (see [Permissions → Read access on Management catalogs](/configuration-and-deployment/enable-security/authorization/permissions.md#management-permissions)).

All three write-paths are recorded here, not only the request-approval path. Approving or rejecting a pending request, creating a binding directly with **Create association**, and removing a binding from **Active associations** each write a row to the same audit stream, and the History tab shows them all:

| Write-path                                 | Recorded as |
| ------------------------------------------ | ----------- |
| Approve a pending request                  | Approved    |
| Reject a pending request                   | Declined    |
| **Create association** (admin direct-bind) | Approved    |
| **Remove** a binding                       | Declined    |

A binding created with **Create association** therefore appears in History as an Approved row, and a removal appears as a Declined row — both attributed to the administrator who performed them. The History tab is a complete record of every association decision on the deployment.

## How `DIRECT_OWNER_SYNC` changes the user-side flow

If a user holds the `DIRECT_OWNER_SYNC` permission — typically granted to a Policy that fast-paths users mapped from a trusted OIDC group — the home-page request form behaves the same, but on submit the platform short-circuits the administrator-approval step entirely. The owner row is created if it did not exist, the binding is written, and the request is recorded as APPROVED in one transaction. The button label on the form changes from **Send a request** to **Associate** to reflect the immediate effect.

The administrator never sees the request on the **New requests** sub-tab; it lands directly on **History** as APPROVED with no human reviewer.

{% hint style="warning" %}
**Operator caution.** Granting `DIRECT_OWNER_SYNC` is consequential beyond "speeding up admin approval." The permission also composes with the new-owner-on-submit behaviour described under [Choosing an owner name](#choosing-an-owner-name) — a holder can mint a brand-new owner name and self-bind to it in one POST. Grant it only to principals you also trust to mint owner names (typically a service identity, not an end-user policy). See the [Permissions](/configuration-and-deployment/enable-security/authorization/permissions.md#management-permissions) page for the full caveat.
{% endhint %}


---

# 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:

```
GET https://docs.opendatadiscovery.org/configuration-and-deployment/enable-security/authorization/user-owner-association.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.