> For the complete documentation index, see [llms.txt](https://wiki.datadike.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.datadike.com/en/get-started/core-concepts.md).

# Core concepts

DataDike PAM has a small vocabulary, and almost every screen in the console is one of the objects below. Learning the six that matter first makes the rest of this documentation read quickly.

## The chain, in one sentence

A **user** is granted an **authorization** that lets them open a **session** to an **account** on an **asset**, over a protocol allowed by that asset's **platform**, through a network path provided by a **gateway** — and the whole session is recorded.

Everything else is a refinement of that sentence.

## The objects

### Asset

Anything the solution brokers access to: a Linux or Windows server, a network device, a database, a web application, a cloud host. An asset is not a credential — it is the destination.

Assets live under **Environment › Assets** and are organized in a folder tree.

### Platform

The *kind* of asset, and what can be done with it: which protocols it accepts, which port each one uses, and which automations it supports — collecting accounts, changing a password, pushing a new account.

A platform is why the solution knows that an asset can be reached over SSH on port 22 but not over RDP. Assets inherit their capabilities from the platform assigned to them.

Platforms live under **Environment › Platforms**.

### Account

A credential on an asset — `root` on a Linux server, `Administrator` on a Windows host, a database login. The account is what the solution stores, rotates, and hands out. Users normally never see its secret.

Accounts live under **Accounts › Accounts**, and always belong to exactly one asset.

### Template

A reusable account definition, so that the same account can exist on many assets without being described one by one. Change the template and the change can be propagated to every asset it covers.

Templates live under **Accounts › Templates**.

### Authorization

The rule that connects the three sides: **who** (users or groups), **what** (assets and accounts), and **how** (which protocols, during which hours, with which command restrictions). No access exists without one.

Authorizations live under **Policies › Authorization**.

### Session

A connection opened through the solution. While it runs it can be watched and terminated; after it ends the recording stays in the audit trail. A session is the unit that auditing is built on.

Sessions live under the **Audit** profile.

## The network path

Three objects describe how the solution reaches an asset, and they are easy to confuse.

| Object        | What it is                                                                                                                                          |
| ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Proxy**     | The component that terminates the user's connection and speaks the target protocol on their behalf                                                  |
| **Gateway**   | A jump host used to reach assets that are not directly reachable from the solution                                                                  |
| **Broker**    | A reverse path, where the target dials out to the solution instead of the solution dialing in — for networks that cannot accept inbound connections |
| **Connector** | The agent installed on a machine that has no gateway in front of it, so that the machine hosts its own path                                         |

## Identity

| Object      | What it is                                                                                                                                      |
| ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| **User**    | Someone who logs in to the console or opens sessions                                                                                            |
| **Group**   | A set of users, used as the subject of authorizations                                                                                           |
| **Profile** | What a user may do *in the console* — administer, audit, or only consume access. Distinct from an authorization, which governs access to assets |

Users can be local to the solution or synchronized from a directory. See [LDAP and Active Directory](/en/administration/identities/ldap-and-ad.md).

## Two distinctions worth getting right

**Authorization is not profile.** A profile decides which console screens a person sees. An authorization decides which assets and accounts they may reach. An auditor may hold a powerful profile and no authorization at all.

**Account is not user.** An account is a credential *on a target*. A user is a person *of the solution*. The point of a privileged access solution is that the two are never the same thing: the person authenticates as themselves, and the solution supplies the target credential.

## Related pages

* [Architecture and components](/en/get-started/architecture.md) — the pieces that run the solution
* [A tour of the console](/en/get-started/console-tour.md) — where each object lives
* [Onboard your first managed asset](/en/get-started/first-managed-asset.md) — the vocabulary in practice
* [Authorizations](/en/administration/access/authorizations.md)