User Access Controls

Each JupiterOne account has one of the following two access control configurations:

• Standard access controls (default on all accounts)
• Granular access controls (available upon request to all PLUS/ENTERPRISE tier accounts)

Standard Access Controls

Standard access contros is the default configuration on all JupiterOne accounts. There are two access levels across all resources:

• Users in the Administrators group have full admin access (including write access) to all resources.

• All other users in other groups have read-only access to all resources, as well as the permission to save queries as questions.

Standard access control is similar to the Top Level Permissions in Granular Access Control.

Granular Access Controls

Granular access controls is available to all PLUS and ENTERPRISE tier accounts. It allows more detailed access configuration at each user group level to achieve role-based access control (RBAC).

Creating custom groups

In addition to the preset groups provided by JupiterOne, JupiterOne admins have the ability to create additional groups within the JupiterOne workspace. This provides the ability to configure groups with granular permissions as desired.

You can view and edit user groups from the User Groups setting

To create a custom group:

1. Navigate to the Settings menu (the cog icon next to notifications).
2. Click on User Groups in the Admin section.
3. From the new window select New Group.
4. Enter the desired Group Name and Group Description, and click Create Group.
5. You will be navigated to the Group's Details page. From here, you can customize the following:

• Query Policies for the User Group
• User Group Permissions

6. Lastly, to add users to the group, navigate to the Group Members tab and select Add Member.

Editing User Groups

Existing user groups can also be edited, and you can make changes to any of the options found under the Details tab and you can also add/remove members from the Group Members tab."

To edit a user group:

1. Navigate to Settings > User Groups.
2. Select the user group from the menu that you wish to edit.
3. Make your desired changes in the Details and/or Group Members sections. Press Save.

NOTE: Changes made to members are saved immediately, only changes made to the user group's details section will need to be manually saved with the Save button. You can also revert accidental changes to a user group by pressing Reset.

Delete a User Group

You can also delete an existing user group by navigating to that user group and selecting Delete at the top right of the window.

Switching User Group views

With the ability to create custom user groups, it is possible for a user to be in more than one group at a time. You are able to switch between each group and their respective views/permissions.

To switch between user groups:

1. Select the profile icon from the JupiterOne dashboard.
2. Choose the group listed under Permission by group, choose the desired group for which you'd like to utilize.

All Permissions will allow for all available permissions across groups that a user belongs to. Permissions across groups are in a sense 'rounded up'. For example, if a user is part of the Administrator group, their edit access from that group would override view permissions in any other group they may be a part of while All permissions is selected. To swap to the read-only view, they would need to choose a particular group.

Query Permissions

Enterprise customers can set query permissions for a user group if you are in the Administrators group. A query permission applies the filter constraints on the data that users in the group are allowed to query. You can configure permission filters by:

• Entity class
• Entity type
• Integration class
• Integration type
• Integration configuration instance

You can add as many filters as you want to the permission set. To configure query permissions:

1. Go to Settings (the gear icon) > User Groups.
2. Select the user group you want to edit.
3. In the Query Policy section, select and add the query type and values for each filter and click Add.

If you want to set up queries based on sets of filters that you want to then link by OR logic, create separate permission sets.

Resource Based Access Control (RBAC)

Resource based access control allows an admin to limit a user group's ability to perform CRUD operations to specific resource groups or even individual resources.

Definitions

• Resource area: A part of the application, such as Dashboards or Alerts
• Resource group: A resource group is a collection of resources that logically belong together to meet a specific use case.
• Resource: A JupiterOne native resource such as a dashboard or rule. Managing access to graph data is separate and detailed in the Query Permissions section.

Resource Groups Setup

You can manage your resource groups in the settings application. To set a resource group on a resource, you visit that application and modify the resource.

RBAC Permissions Setup

You can manage RBAC permissions at the user group level in the settings app. Below are some of the supported use cases.

Resource Group Admin

Assigning resources to a resource group, and giving a user group access to that resource group is the best way to manage resource access.

This group can create, read, update, and delete dashboards within a single resource group.

Resource Group Readonly

This group can read dashboards within a single resource group, but cannot create or update dashboards. This user will have read access to all future dashboards that are created within this resource group.

Resource Area Admin

This group can read, update, and delete all dashboards as well as create dashboards within any resource group. They can also create dashboards outside of resource groups.

Granular Resource Access

This is a group that has access to only a few dashboards. This group cannot create dashboards because only a resource area admin can create resources outside of resource groups.

NOTE: We recommend you stay away from granular resource access unless it is very limited in scope. Managing access this way, without resource groups, can become very cumbersome and runs into some system limitation that are set in place.

RBAC Limitations

• A resource can only be part of a single resource group, but multiple groups can have access to that resource group.
• No Resource Group is not a resource group itself. You cannot give a group access to all resources that do not have a resource group. You can, however, create a resource group called 'General', and assign resources to that group.
• The application and api will only respect a combination of 100 different RBAC permissions per user/token session. This is why we recommend managing access at the resource group level. A resource group can have hundreds of resources, and that is managed through a single RBAC permission on the resource group. The api and UI will warn users when they are accessing JupiterOne with too many permissions, and therefore can only view a subset of their total configured permissions. This especially comes into play when a user is part of multiple user groups.
• Limiting read access to resources via RBAC permissions does not limit viewing associated entities in the graph, such as rules and alerts. That limitation can be added separately via query filters.

App Permissions

Permissions are configured per group, and any users in a group can perform the actions assigned by the permissions editor. Changes to a group's permissions may take up to five minutes to propagate.

Each app level category has two permissions: Read-only and Admin. Admin permissions will allow all actions included in the Read-only permissions for each app.

Each shared permission has two permissions: Read and Write. Read permissions will allow access to retrieving the resource, while Write will allow mutating / editing of the resource. Write permission does not implicitly grant Read permission in this case, unlike how admin permissions grant read-only permissions implicitly in the case of app level permissions.

Top Level Permissions

Top level permissions applies to all apps and pages.

• If a group is assigned top level Admin access, users in that group will be allowed to perform any action in any app as well as on shared resources.

• If a group is assigned top level Read-only access, the users in that group will be allowed to access all apps and read all data including on shared resources, however they will not be able to perform actions that require write level permissions (e.g. creating a rule in the Alerts app).

Global Shared Permissions

Shared permissions are not bound to a specific app, but are relevant to resources that span different apps.

List of shared permissions:

• Graph Data (used anywhere entity and relationship data is retrieved on demand or when entities / relationships are mutated directly; also used for raw data associated with entities)

NOTE: This permission does not completely restrict the ability to query graph data. You should limit access to graph data through the Query Permissions described above.

• Questions (saved J1 queries used in the Home page Questions Library and in Compliance app for mapping to compliance requirements)

Some of these permissions are needed for an app to function fully. For example, you are not able to use the Insights app without read permissions for Graph Data because the dashboards and widgets cannot load the data.

App Level Permissions

App level permissions such as for Alerts and Assets apply to the application pages shown primarily on the app switcher. However, a few other categories have been added including Integrations and Endpoint Compliance Agent despite their not strictly be apps, they function as one and it is easy to group their responsibilities together.

Admin permissions for each app allows certain administrative actions unique to each app. For example, add a new standard / questionnaire in Compliance app; save board layout as default in Insights app; etc. Certain actions also require shared permissions to global resources to be enabled.

Users not assigned any access at either top level or app level permissions will receive an "Access Denied" error message when attempting to navigate to the app.

The full list of the apps is here, along with shared permissions that may be used by features in each app:

note

You may see a subset of these apps in your settings based on your account subscription level.

• Home (the base/root page - /home)

  Shared permissions used by this app: Read / Write Questions and Read Graph Data for access to Questions Library and running J1QL queries respectively. Optionally Write Graph Data for editing entities from query results.

• Assets (URL ending with /inventory)

  Shared permissions used by this app: Read / Write Graph Data (app is unusable without Read Graph Data, Write Graph Data used for editing entities).

• Policies (URL ending with /policies)

  Shared permissions used by this app: Read Graph Data for loading the policy elements and raw data, and Write Graph Data for saving changes to the policy entities.

• Alerts (URL ending with /alerts)

  Shared permissions used by this app: Read Graph Data (need only for the Vulnerability Findings view, the Alerts view will load results from a historical snapshot and does not need Read Graph Data permission).

• Compliance (URL ending with /compliance)

  Shared permissions used by this app: Read Graph Data for expanding queries used as evidence to view results, Read / Write Questions for editing the questions used in this app.

• Graph Viewer (URL ending with /galaxy)

  Shared permissions used by this app: Read Graph Data. App will not function without this permission as it is focused on graph exploration.

• Insights (URL ending with /insights)

  Shared permissions used by this app: Read Graph Data. Dashboards and widgets will not load without this permission.

• Integrations (URL ending with /integrations)

  Shared permissions used by this app: none.

• Endpoint Compliance Agent "Power up" (URL ending with /powerups/endpoint-agent)

  Shared permissions used by this app: Read Graph Data, used to fetch users and devices.

Recommended Permissions

Default User Group

For the default Users group with the most limited access, set a minimum Query Permission Set. The minimum recommended group is _class:Root. This permission group only includes the root organization.

Set the Read-only permission for Policies in App Permissions to allow users to Review & Accept organizations policies.

Compliance and Audit Group

For a group of users focused on compliance and audit processes, the integrations relevant to the scope of the audit must be included in the query permissions. It is recommended that App Permissions for this group include Admin access to Compliance and Policies, as well as Read-only access to Assets.

Integration Service Admin

For a group where configuration of integrated services is necessary, the recommended App Permissions for this group include Admin access to Integrations. In cases were Endpoint Compliance is used, Admin access is necessary for this App Permission as well. The minimum Query Permission Set, _class:Root, is recommended for this group, but may be necessary to expand in special cases.

It may be necessary to expand access for this group in cases where SAML and SSO configuration must be configured.