Identity and Access Management (IAM)

We care deeply about liberating data at Cognite. Much of the liberation is about removing the obstacles users face when they try get their hands on information. We believe that by having access to data by default within the organization, as opposed to having to request access per data set, enables faster and wider innovation on that data and the information it holds. At the same time, we realize that not all data can be accessible by the entire organization, there may be data that are sensitive for market or personal information that must be restricted. Also, there is a need to grant access to data to external parties, and in this case it is important to clearly scope what data access is granted for.

Identity and access management is a framework which allows for controlling which users and applications has access to data in the Cognite data platform (CDP). Details on authentication and authorization are found in the respective concept introductions.


  • Principal: A principal is a user or service that is recognizable by the system as a individual entity. Each entity has a unique identity which makes the system able to distinguish between individual principals.
  • Request: A request is carrying an operation a particular principal wants to execute against CDP. Each request contains information about what operation, such as read or update, which principal is requesting to have the operation carried out, and on which resource. A resource could for example be a particular file.
  • Authentication: When a principal sends a request to CDP, the claimed principal must be checked so that CDP knows which principal the request is from. Users are authenticated directly or indirectly through an identity provider (such as Azure AD or Google). Services are authenticated by presenting a secret API-key. Requests from principals that cannot be authenticated are denied. Specifics can be found in authentication.
  • Authorization: After the principal of the request is validated in the authentication step, CDP will assess whether the principal has access to perform the requested operation and allow or deny the request accordingly. Based on the identity of the principal, the relevant capabilities will be resolved and evaluated against the operation in the request and the applicable resources. This process is detailed in authorization.
  • Identity provider: An identity provider is a service that can be used to authenticate users. This is also the service where organizations typically will manage the users of their organization. The most common identity provider is Azure Active Directory (Azure AD).


Identity management allows you to manage which users and services are able to connect to your project in CDP. In other words, which principals CDP will be able to authenticate. Only authenticated principals will be able to interact with CDP to retrieve or store data there.

Identity Provider

As CDP authenticate users against the organization's Identity Provider, the organization is in full control of which users are authenticated. Any user they for example disable in Azure AD, will not be able to log into applications and see data from CDP. They can also create guest users in the identity provider, to allow for users from other organizations to be authenticated.

Valid domains

As part of the authentication flow against the identity provider, CDP will check each user against a set of valid domains. If any such valid domains are configured in CDP, only users that have been authenticated by the identity provider, and is from the configured domain will be considered authenticated.

Configuring valid domains is done as part of configuring the identity provider for a project in CDP.


Users are managed in the existing identity provider of the organization, typically this will be Microsoft’s Azure Active Directory (Azure AD). To start using CDP, one need to configure the connection to the identity provider, so that CDP can authenticate all the users from that Identity provider. The identity provider configuration consist of which service instance to talk to, and optionally which domains the user need to belong to in order to be authenticated.

CDP must successfully authenticate the user against the identity provider before the user is allowed to access CDP. This requires that the application the user is leveraging has implemented the required authentication flow. The Operational Intelligence application is an application that implements the required authentication flow. This makes users of the Operational Intelligence application interact with CDP, with their own principal, and therefore able to see all the data they have access to from CDP in the application.

Service Accounts

A service that needs its own identity can for example be an extractor that ingest data into CDP, or a machine learning model predicting chance of equipment failures. These are examples of services that interacts with CDP on its own behalf and, not on behalf of a particular user.

Service identities are managed within CDP through the management of API keys. Each API key should be used by a single service. When CDP receives a request that carry an API-key, CDP will authenticate the sender as a service principal. Authentication is done in CDP in this case, with no involvement of the Identity Provider.


Groups are defined per project and provide additional information about the principals in a group. They are primarily used for authorization, as they include a set of capabilities that principals in the group are provided. Group membership can be stored in CDP for service accounts, or may be dynamically determined from Azure AD group memberships, if the sourceId for a CDP group matches the GUID of a group in Azure.

Last Updated: 12/13/2018, 1:12:02 PM