# Squirro Roles & Permissions To control access to different parts of a Squirro installation, Squirro provides different roles, each with its own unique set of permissions. There are two primary levels of roles and permissions within Squirro: - Server-level roles - Project-level roles This page describes how server and project roles and permissions are assigned and managed. > **Important** > > People must first be added at the server level before they can be added to a project. You cannot give a person access to a project without first adding them to that project’s server. ## Cluster Permissions There is a third level of permissions, Cluster, that only applies to Squirro Self-Service instances. For an overview of Cluster roles and permissions, including mapping to server roles, see [Cluster Roles and Permissions for Self-Service](../../getting/self-service/cluster-permissions.md#self-service-permissions). ## Server-Level Permissions At the server level, there are three roles: - Administrator: The top-level permission role able to perform all functions. - User: Able to view projects they’ve been added to and connect to them via API. Can also create new projects. - Restricted: Read-only access to the server. > **Note** > > There is a deprecated role called _Demo_ that can be ignored. Roles and their associated permissions are outlined in the table below: | Permissions | Administrator | User | Restricted | | --- | --- | --- | --- | | View projects they’ve been added to | | | | | Change their _My Account_ information | | | | | Access instance API information | | | | | Create new projects | | | | | Access the Server Space | | | | | Access the Squirro Monitoring Space | | | | ### Two Ways People Can Be Added to the Server How users are added to your server depends on whether or not your Squirro installation utilizes Single Sign-On (SSO). If your instance has SSO turned on, then users may only be added through the configured third-party SSO provider. > **Note** > > After a person is authenticated via SSO for the first time, they are created in the Squirro Server space. If your project does not use SSO, then users may be added via the Server → Users page. ### Setting Up SSO If you are looking to set up SSO (SAML) for Squirro, see [SAML SSO for Squirro](../admin/external-authentication/saml-sso.md#admin-saml-sso). ### Configuring Roles and Permissions via SSO You can manage role assignments through the Single Sign-On (SAML) menu option within the Server space. To do so, follow the steps below: 1. Log in to your Squirro installation as a server administrator. 2. Navigate to the Server space. 3. Click Single Sign-On (SAML) in the left menu. 4. Use the _Mapping of groups to Squirro roles_ field to assign permissions as shown in the screenshot below: [](https://s3.amazonaws.com/download.squirro.net/docs/technical/ui/saml-config.png) > **Notes for administrators** > > - When SSO is turned on, the role mapping configuration is the source of truth for server-level roles. Manual role changes made through the Squirro UI are temporary and reset when the user logs in again. > - Squirro recommends turning off UI user management so that user provisioning is managed exclusively by your identity provider (IdP). See the [Enabling and Disabling UI User Management](../admin/external-authentication/disable-sso.md#admin-sso-disable) page. ### Adding People and Managing Roles and Permissions with SSO Turned Off If your installation does not use SSO, follow the steps below to add users or manage roles and permissions via the Squirro UI: 1. Log in to your Squirro installation as a server-level Administrator. 2. Navigate to the Server space. 3. Click Users in the left menu. 4. Click the plus icon to add a new user and assign roles (as shown in screenshot below) **or** hover over an existing user and click Edit to modify their details. [](https://s3.amazonaws.com/download.squirro.net/docs/technical/ui/create-user-non-sso.png) ### Squirro Monitoring Only server-level Administrators have access to [Squirro Monitoring](squirro-monitoring.md#ui-squirro-monitoring), which serves as the central activity and data ingestion log monitoring hub for all projects on a Squirro installation. ## Project-Level Permissions At the project level, there are three roles: - Administrator - Member - Reader > **Note** > > There is also an Owner role that shares the same permissions as the Administrator role, but only applies to the person who created the project. There is no functional difference between the two roles. Roles and their associated permissions are outlined in the table below: | Permissions | Administrator | Member | Reader | | --- | --- | --- | --- | | Read items | | | | | Manage sources | | | | | Manage dashboards | | | | | Manage saved searches | | | | | Access the Setup Space | | | | | Manage project members | | | | | Delete project | | | | The Member role has access to most Setup space features. It does not, however, have access to most items within the _Settings_ tab. The project-level Administrator role has Setup space permission levels halfway between a Member and a Server Administrator. The project-level Administrator can view more _Settings_ than the Member, but it cannot see the _Studio_ settings managed by server-level administrators. > **Note** > > If you require Readers to change the fields of an _Items_ widgets (which they cannot do by default), enabling `topic.item.allowed-reader-edit-keywords` will permit them to do so. You can find this setting by navigating to Setup → Settings → Project Configuration. ### Reader Permission for Read and Bookmarked State Users with the Reader role receive special permissions that allow them to track reading progress and bookmark items without granting full item update capabilities. The Reader role includes the following permissions by default: - **items.write.update.read_state** Allows Readers to mark items as read or unread and track personal reading history. - **items.write.update.starred_state** Allows Readers to bookmark items by adding them to collections. This permission name reflects the legacy starred system. The permission now enables adding items to the Bookmarks collection and other personal collections. These permissions do not grant the ability to modify item content, metadata, or other properties. They apply only to the read state and collection membership. Administrator and Member roles receive the broader `items.write.update` permission, which includes these capabilities plus full item modification rights. The Reader role permissions are defined in the platform configuration and cannot be modified through the user interface. For detailed information about read and bookmarked items functionality, see the [Read, Unread, New, and Bookmarked Items](items-interaction.md#ui-items-interaction) page. ## Groups A user group is a named set of users that can be given a role in a project in a single step. Groups are created on the server level in the Server space, but their permissions are applied at the project level in the Setup space under Settings → Project Members. Groups are a useful (and recommended) tool for managing user permissions, particularly if your project uses SSO. For how to create a group, manage its members, and share it with a project, see the [Managing User Groups](user-groups.md#ui-user-groups) page. Under the Single Sign-On (SAML) configuration option within the Server space, you can map Squirro roles by group using the _Group Names Field_ based on their roles/groups in the SSO identity provider (IdP), as shown in the screenshot below: [](https://s3.amazonaws.com/download.squirro.net/docs/technical/ui/map-groups.png) ## Dashboard Permissions In addition to the roles and permissions outlined on this page, you can also restrict access to individual project dashboards under the Setup > Visualization space. To learn more, see [Dashboard Permissions](../dashboards/dashboard-permissions.md#dashboards-permissions).