By connecting CDF to your identity provider (IdP), you can use the IdP framework to manage access to CDF data securely. This article explains the design principles and best practices to manage access to CDF.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.
Design principles: OpenID Connect and CDF
This section outlines the design principles to manage access to CDF.Authentication and applications
Authentication is about determining the identity of a person or application trying to access a resource. It establishes if they are who they say they are. Applications and users need to get a token from the IdP to authenticate and get access to CDF. The token is a very targeted key that grants access to an identity (a user identity for people, a service principal for applications.)Authorization and groups
Authorization is about determining what level of access an authenticated person or application has. It specifies what data they’re allowed to access and what they can do with it. Access to CDF data and capabilities in CDF projects are governed by policies defined in the customer’s IdP and by resolving the policies into one or more CDF groups where the access scope is defined. The policies are specified in the claims in the tokens that the IdP issues. You can configure CDF groups to use any OAUTH v2.0 claim to determine access. The most commonly used claim type isgroups, which is also the claim type recommended by Cognite.
You need to create AD groups to govern access rights to CDF for applications (service principals). For each security group a service principal is a member of, a groups claim is created and entered into an access token for the service principal.
Best practices: Register applications and set up groups
This section outlines the best practices for registering and configuring applications to authenticate with CDF. You’ll also find information about setting up groups to authorize what data users and applications can access and what they can do with the data.Register and configure applications for authentication
The general rules for applications are:- Service applications (applications that have no human interaction, for example extractors) use the client credentials authentication flow. Service applications are sometimes referred to as daemon applications. You need to register each service application separately to provide specific access for different service applications and distinguish between security contexts.
- User applications (applications that require human interaction, for example the CDF application, connectors, and web applications) use either the authorization code grant flow or the implicit grant flow, depending on the implementation choices of the client application. Where supported, you should use PKCE.