User and Group Management
As an administrator, you will need to manage users and groups that are accessing your instance. The way users are added to Connect will depend on the authentication mechanism you use. Their role (Administrator, Publisher, or Viewer) will be assigned depending on your configuration and authentication settings. This lesson provides an overview of the administrative tasks you can perform to manage users once they have been created on the Connect server, and their groups.
- Reading time: 15 minutes
- Documentation reading time: 25-45 minutes
- Hands-on exercise time: 15-30 minutes
Key stakeholders involved in user and group management:
| Stakeholder Role | Core Responsibility | Key Action |
|---|---|---|
| 1. Application Administrator (Software/App Admin) | Manages the user account and permissions within the application itself. | Manages the software, updates the configuration to use authentication applications, may consume groups created upstream or manages groups inside the application. |
| 2. IAM Administrator (Auth Admin) | Manages the central Identity Provider (IdP) and the authentication process. | Configures SSO, monitors automated provisioning/de-provisioning syncs, and manages security groups in the IdP. |
| 3. User Data/Group Manager (HR/Service Desk) | Manages the source of truth data and the groups that drive the access. | Ensures user attributes are correct, adds users to the trigger access groups, and initiates onboarding/offboarding. |
There are 3 ways to manage users and groups in Connect:
- through the web interface;
- using the
usermanagerCLI utility that gets installed in the/opt/rstudio-connect/binfolder on the server where Connect is runnin; - using the web API, directly or through the R or Python SDKs.
The table below shows common user and group management tasks and which methods support them. “Local” refers to users known to Connect, and “remote” to users that only exist in the authentication system.
In the table below, some tasks can be performed regardless of the authentication provider you use (✅), others depend on the authentication method (🟡). Check the documentation for more details.
| Task | Web Interface | CLI\(^1\) | API |
|---|---|---|---|
| List/search local users and groups\(^2\) | ✅ | ✅ | ✅ |
| Change local user role | ✅ | ✅ | ✅ |
| Local group membership\(^2\) | ✅ | ✅ | |
| Create local user | 🟡 | ||
| Search for remote users | 🟡 | ||
| Get local user/group details | ✅ | ✅ | ✅ |
| Update local user/group info\(^2\) | 🟡 | 🟡 | 🟡 |
| Lock local user | ✅ | ✅ | ✅ |
| Transfer content ownership | ✅ | ||
| Delete local user | ✅ | ||
| Delete local group\(^2\) | 🟡 | 🟡 |
\(^1\): Note that the CLI utility requires the Connect service to be stopped unless your installation uses PostgreSQL for internal storage. We recommend using it only for tasks that require this utility, such as transferring content ownership and deleting users.
\(^2\): Groups are useful to grant viewer or collaborator access to multiple people based on teams or projects. Just like users, groups can be managed locally, or remotely. Locally, groups are managed either using the web interface, the usermanager CLI utility, or the Connect API. With remote group management, Connect relies on the information coming from your authentication provider.
To learn more about user and group management in Connect, especially the actions that can be taken with the CLI utility or the API, check the following resources:
usermanagerCLI documentation- Connect API documentation for user management and for group management
In the lab accompanying this lesson, you will get to practice user management and access using the web interface and the command line.