Skip to content

Click in-app to access the full platform documentation for your version of DataRobot.

Authentication, roles, and permissions

DataRobot employs many layers of security to help protect customer data—at the architecture, entity access, and authentication levels. The sections on this page detail roles and permissions at each level.

General access guidance

Access is comprised of roles and permissions. Roles categorize a user’s access; permissions specify the function-based privileges associated with the role.

Role definitions

In general, role types have the following access:

Role Access
Consumer/Observer Read-only
Editor/User Read/Write
Owner Read/Write/Administer

Role priority and sharing

Role-based access control (RBAC) controls access to the DataRobot application and is managed by organization administrators. The RBAC roles are named differently but covey the same read/write/admin permissions. The assigned role controls both what you can see when using the application and which objects you have access to.

RBAC overrides sharing-based role permissions. For example, let's say you share with another user who was assigned the RBAC Viewer role (Read-only access) by the admin. You grant them User permissions (Read/Write access). However, because the Viewer role takes priority, the user is denied Write access.

A user can have multiple roles assigned for a single entity—the most permissive role takes precedence and is then updated according to RBAC. Consider:

  • a dataset is shared to an organization, with members assigned the consumer role. The same dataset is shared to a user in that organization with the editor role. That particular user will have editor capabilities, other organization members will be consumers.
  • a dataset is shared to a group, with members given owner permissions. You want one user in the group to have only consumer access. You must remove that user from the group and reassign them individually to lessen their permissions.

Sharing

Access to sharing can be found as a button (AI Catalog) or an icon (), in or independent of a menu (deployments and projects).

When you invite a user, user group, or organization to share a project, DataRobot assigns the default role of User or Editor to each selected target. (Not all entities allow sharing beyond a specific user.) You can change the role from the dropdown menu:

Note the following when sharing or removing access:

  • You can only share with active accounts.
  • You can only share up to your own access level (a consumer cannot grant an editor role) and you cannot downgrade the access of a collaborator with a higher access level than your own.
  • Every entity must have at least one owner (entity creator by default). To remove the creator, that user must assign the owner role to one or more additional collaborators and then remove themselves.
  • Data connection and data asset entities must have at least one user who can share (based on the “Allow sharing” setting).

The elements of the sharing modal depend on the entity you are sharing. Fields are described below with entities of specific fields noted.

Field Description
Add names
Role Sets the role, and therefore the access, for the user/group/organization being added.
Allow sharing (AI Catalog, data connections) Provides the collaborator with permission to re-share the asset with others (up to their level of access).
Can Use Data (AI Catalog) Allows the collaborator to use the dataset for certain operations (e.g., download data, create project from dataset).
Enter name(s) Adds users/groups/organizations to the entity. Start typing to see matching names (names that appear are those that you have permission to share with). Click on a name to add it to the "Share With" field. These are the entity's collaborators. You can add up to 100 names per request, there is no limit total.
Optional note (Projects) Add a note, up to 500 characters, which will be included in the notification that DataRobot sends to the collaborator.
Share button Adds access for the specified names to the entity. Activates when at least one name is entered. Changes are reflected in the fields below the button.
Users/Groups/Organizations: click tab to view
Shared with A list of names the entity is shared with. The current user (owner, if the only user) always displays in the User tab. If there are no groups or organizations collaborating with the entity, no results display.
Role Sets the role for the user/group/organization being added.
Entity-specific options Allows resetting any options that were set in the section above. Use this to change permissions for a subset of a larger named collaborator.

Project roles

The following table describes general capabilities allowed by each role. See also specific roles and privileges, below.

Capability Owner User Consumer
View everything
Launch IDEs
Make predictions
Create and edit feature lists
Set target
Delete jobs from queue
Run Autopilot
Share project with others
Rename project
Delete project
Unlock holdout
Clone project

Shared data connection and data asset roles

To support nuanced access across collaborative enterprises, there are three user roles to define different capabilities. The roles represent three levels of permissions across data connections and data sources (entities). When you share entities, you must assign a role to the user(s) you share with:

Note

Only an administrator can add database drivers.

  • Editor: An active user of an entity. This role has limitations based on the entity (read and write).
  • Consumer: A passive user of an entity (read-only).
  • Owner: The creator or assigned administrator of an entity. This role has the highest level of access and ability (read, write, administer).

The following table indicates which role is required for tasks associated with the AI Catalog. The table refers to the following roles:

  • Consumer (C)
  • Consumer w/ data access (CA)
  • Editor (E)
  • Editor w/ data access (EA)
  • Owner (O)
Task Permission
Data store/Data connections
View data connections C, CA, E, EA, O
Test connections C, CA, E, EA, O
Create new data sources from a data connection E, EA, O
List schemas and tables E, EA, O
Edit and rename data connection E, EA, O
Delete data connection O
Dataset/Data asset
View metadata and collaborators C, CA, E, EA, O
Share Collaborators can share with others, assigning a role as high as their own role. For example, a Consumer can share and assign role Consumer but not role Editor. Owner can assign any of the roles.
Download data sample CA, EA, O
Download dataset CA, EA, O
View sample data CA, EA, O
Use dataset for project creation CA, EA, O
Use dataset for custom model training CA, EA, O
Use dataset for predictions CA, EA, O
Modify metadata E, EA, O
Create new version (remote or snapshot)* EA, O
Reload** EA, O
Delete dataset O

* "Remote" refers to information on where to find data (e.g., a URL link); "snapshot" is actual data

** If the dataset is "remote," it is converted to a snapshot

Deployment roles

The following table defines the permissions for each deployment role:

Capability Owner User Consumer
Consume predictions*
View deployment in inventory
Get data via API
Replace model
Edit deployment metadata
Delete deployment
Add user to deployment
Change permission levels of users ✔**
Remove users from shared deployment ✔***

* Consumers can make predictions using the deploy API route but the deployment will not be part of their deployment inventory.

** To Consumer or User only.

*** Can remove self only if there is another user with the role of Owner.

Model Registry roles

The following table defines the permissions for each model package role:

Option Description Availability
View a model package View the metadata for a model package, including the model target, prediction type, creation date, and more. Owner, User, Consumer
Deploy a model package Creates a new deployment with the selected model package. Owner, User, Consumer
Share a model package Provides sharing capabilities independent of project permissions. Owner, User, Consumer
Permanently archive a model package Provides sharing capabilities independent of project permissions. Owner

Custom Model and Environment roles

The following tables defines the permissions for each custom model or environment role. Note that there is no editor role for custom environments, only for custom models:

Environment Roles and Permissions

Capability Owner Consumer
Use and view the environment
Update metadata and add new versions of the environment
Delete the environment

Model Roles and Permissions

Capability Owner Editor Consumer
Use and view the model
Update metadata and add new versions of the model
Delete the model

*All roles are able to share an application by sharing the application link with an embedded authorization token.

Automated Application roles

The following table defines the permissions for each role supported for Automated Applications.

Capability Owner Editor Consumer
Make predictions
Deactivate an application
Share an application to other DataRobot licensed users
Delete an application
Upgrade an application
Update an application's settings

Authentication in DataRobot

DataRobot ensures authentication and security using a variety of techniques. When using the database connectivity feature, for example, you are prompted for your database username and password credentials each time you perform an operation that accesses your organization's data sources. The password is encrypted before passing through DataRobot components and is only decrypted when DataRobot establishes a connection to the database. DataRobot does not store the username or password in any format.

Managed AI Cloud: To log into the application website, users can choose to authenticate by providing a username and password or they can delegate authentication to Google. The authentication process is handled over HTTPS using TLS 1.2 to the application server. When the user sets their password, it is securely stored in the database pictured above. Before the password is stored, it is hashed and uniquely salted using SHA-512 and further protected with Password-Based Key Derivation Function 2 (BPKDF2). The original password is discarded and never permanently stored.

On-Premise AI Cluster, Private AI Cloud, and Hybrid AI Cloud: To log into the application website, users can choose to authenticate by providing a username and password or delegate authentication to LDAP. SSO using SAML 2.0 is also supported. For Hadoop installations, Kerberos and SAML impersonation can be used. The authentication process is handled over HTTPS using TLS 1.2 to the application server. When the user sets their password, it is securely stored in the database pictured above. Before the password is stored, it is hashed and uniquely salted using SHA-512 and further protected with Password-Based Key Derivation Function 2 (BPKDF2). The original password is discarded and never permanently stored.

DataRobot also provides enhancements to password-based authentication, including support for multifactor authentication (MFA) with software tokens generated using Time-based One-time Password (TOTP).

All API communications use TLS 1.2 to protect the confidentiality of authentication materials. When interacting with the DataRobot API, authentication is performed using a bearer token contained in the HTTP Authorization header. Use the same authentication method when interacting with prediction servers via the API. While it is possible to authenticate using a username + API token (basic authentication) or just via an API token, these authentication methods are deprecated and not recommended. An additional HTTP Header named datarobot-key is also required to further limit access to the prediction servers.


Updated October 26, 2021
Back to top