> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cognite.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Access management concepts

> Main concepts in securely managing access to the Cognite applications and the data stored in your Cognite Data Fusion (CDF) projects.

<a id="organizations-clusters-and-projects" />

## Organizations, clusters, and projects

When you subscribe to CDF and connect to and use our cloud-based apps and services, you'll manage a CDF **organization**. An organization is a collection of CDF **projects**, and the data in one project is **completely isolated** from the data in other projects.

Depending on your existing infrastructure and needs, you decide which **cluster** to run your CDF organization in. A cluster determines which **cloud provider** to use; Microsoft Azure, Amazon Web Services (AWS), or Google Cloud Platform (GCP). Each provider has [different clusters](/cdf/admin/clusters_regions#cognite-multi-tenant-clusters) to store data in your preferred **region**, such as North America, Asia, or Europe.

Also, you can choose between a **multi-tenant** or a **dedicated** cluster:

* In a **multi-tenant** cluster, you share cloud storage and computing resources with other Cognite tenants.

* In a **dedicated** cluster, your organization uses cloud storage and computing resources exclusively. To request a dedicated cluster, contact your Cognite representative.

You can configure your organization to use your existing **identity provider (IdP)** — for example, Microsoft Entra ID, Amazon Cognito, or Auth0 — to manage access to your CDF projects. Only users registered in your IdP can sign in to the organization and the projects. Each CDF organization can be configured with **only one** identity provider. **All** projects in the organization are automatically configured to use the identity provider configured for the organization.

<Frame>
  <img src="https://apps-cdn.cogniteapp.com/@cognite/docs-portal-images/1.0.0/images/cdf/access/concepts_v3.svg" alt="Access management concepts" width="60%" />
</Frame>

When users sign in to their organization, they see a list of the projects they can access.

<Note>
  For a project to appear in the list of available projects, a user needs to be a member of at least one group in the project.
</Note>

The first time users sign in to their organization, CDF creates an organization **user profile** for them from the information in the IdP. The profile typically includes the user's first and last name, email, and job title.

<a id="principals-user-accounts-and-service-accounts" />

## Principals, user accounts, and service accounts

**Principal** is an umbrella term for **user accounts** and **service accounts**. Both entities can be uniquely identified, authenticated, and authorized in CDF. Principals are unique within an organization and not within a project in the organization. Principals can access data and create and run processes (transformations, Functions) in a CDF project.

* A **user account** is associated with a **person** who wants to interact with CDF. Each user account has a user profile containing a unique user ID.

* A **service account** is associated with an **application** or **process** that wants to interact with CDF, such as an extractor or Cognite Functions, rather than a person.

```mermaid theme={"languages":{"custom":["/_languages/kuiper.json","../_languages/kuiper.json"]}}
flowchart LR
    A[Principal]
    A --> B[User account]
    A --> C[Service account]
```

<a id="capabilities-and-groups" />

## Capabilities and groups

**Capabilities** define what permissions principals (user accounts and service accounts) have to work with different **data** resources in a CDF project, for example, if they can read a time series (`timeseries:read`). Capabilities also decide which **features** they have access to. For instance, they need the `3d:create` capability to upload 3D models to CDF.

<Frame>
  <img src="https://apps-cdn.cogniteapp.com/@cognite/docs-portal-images/1.0.0/images/cdf/access/groups_in_cdf.svg" alt="Groups in CDF" width="50%" />
</Frame>

A capability is defined by a **resource type**, a **scope**, and **actions**. The resource type and scope define **the data** the capability applies to, while the action represents **the operations** you can perform.

Instead of assigning capabilities to individual users and applications, you use **groups** in CDF to define what capabilities members (user accounts or service accounts) have.

You can manage group membership with your identity provider (IdP), CDF, or a combination of both.

<a id="cdf-administrators" />

## CDF administrators

CDF has two levels of administrators (admins):

* **Organization (org) admins** can update the identity provider (IdP) configured for the organization.

* **Project admins** can create new groups and add or remove capabilities and scopes from groups in a project. Typically, they're members of a group with the `groups:create` and `groups:delete` capabilities.

<a id="cdf-audit-logs" />

## CDF audit logs

You can control access to the Cognite API through group membership. When a principal makes a request to the API, it's captured in the CDF audit logs. The CDF audit logs contain the following information:

* Who: principal ID (user or service account)
* When: timestamp
* What: project name, request URL, group IDs
* Where: CDF headers in the request (`x-cdp-sdk`, `x-cdp-app`, `x-cdp-clienttag`)

Audit logs contain detailed information from all valid access tokens used to make the requests. They are stored for 400 days and can be requested in case of a security incident.