User accounts in RStudio Connect associate users from an authentication provider
with a set of capabilities (default role plus content specific permissions).
RStudio Connect can integrate with different authentication providers (as described
here, with varying degrees of customization / control for general user attributes.
Within RStudio Connect, every user account is configured with a "role" that controls their default capabilities on the system. Their "permissions" to access and manage content which has been published to the RStudio Connect server may vary, depending on what has been granted to their account by the content owner (the account which published the content to the server).
property specifies the role for new accounts and defaults to
Authorization.DefaultUserRole may be either
accounts are not permitted to automatically have the
administrator role. For
all authentication providers, the first user is always created as
There are no restrictions regarding roles for the users created via the Connect Server API.
User accounts may be assigned any of the following roles, with the exception of Anonymous, which is the role which non-authenticated users are assigned automatically.
The role of "administrator" requires system permissions and access typically only available to IT support staff. Data scientists, analysts and others working in R or Python will most likely want "publisher" accounts as they will need to publish content to the server. Users who view or consume the published content are likely to need only "viewer" accounts but in some cases when viewing unrestricted content, may be able to use "anonymous" access (in which case, they will not have an account within RStudio Connect).
Your external authentication provider may be able to return user profile information that maps to valid user roles in RStudio Connect. For example, the user's position or department may be available as part of the user attribute returned during authentication and these could be leveraged to select a user role. Further details specific for each authentication provider can be found within the Authentication section.
- RStudio Connect administrator accounts have permissions which allow them to manage the service. This includes setting the role of an account. Administrators may or may not be system administrators.
- Administrative users on RStudio Connect are empowered to inspect and manage various settings on the server. Regardless of their level of privilege on some piece of content (viewer, collaborator, or neither), administrators can manage collaborators and viewers on content, manage the runtime settings for Shiny applications and Plumber APIs, and adjust the schedules for R Markdown documents. Additionally, only administrators can modify the Vanity Path and RunAs settings (User Account for Processes) for content through the Connect dashboard; they can do so even on content that they don't have the ability to view the content.
Administrators do not have implicit rights to view content or download the source bundles. If an administrator visits a report without viewership privileges to the report, they will see a request access page rather than the report's content. Despite being unable to see the contents of the report, administrators can still manage the settings for all content. Because an administrator has the ability to manage the collaborators and viewers of others' content on the system, they can choose to add themselves as a viewer or collaborator on the report to gain access. Administrative overrides of permissions on content require that the administrator take an explicit action which is captured in the audit log.
Administrators have all the permissions of Collaborators. Administrators are not automatically added to content and will not see all content on their homepage. Administrators can proactively add themselves as Collaborators or Viewers to any content. Administrators can set custom "vanity" URLs and change the
RunAsuser. Administrators and the original content owner can delete content.
- Accounts with a "publisher" role are allowed to deploy content into RStudio Connect. They are able to configure settings and access controls associated with the content they have published. They can also help manage another user's content when made a "collaborator" of that content.
It's possible to allow collaborators to set custom "vanity" URLs with
Please note that these custom URLs set by collaborators must not begin
with any existing username, for security reasons. Only Administrators have
By default, publishers cannot add new users or groups to RStudio Connect. If your use case requires publishers to have such privileges, please see the section on Publisher Ownership of Groups, and Users Provisioned By Publishers on the Advanced User / Group Topics appendix.
- "Viewer" accounts can be added as a viewer to specific content.
Viewers can sign into the Connect dashboard. They can discover and access
content listed for
All users - login required, and content for which they are granted access. They can access the settings associated with any of the content they are able to view. Viewers can also email themselves copies of documents they are permitted to see. Viewers can also see all users and groups in RStudio Connect.
Any logged-in user can list all the other existing users. To limit what
viewers can see use
- An anonymous visitor to RStudio Connect who is not authenticated with the system can view content that has been marked as viewable by "Anyone". Anonymous viewers access content through direct URLs and will not have any view into Connect.
The functionality available to any user for any specific piece of content will depend upon their default role and the specific permissions they have been granted. Permissions modify the user's role downward (becoming more restrictive) for a specific piece of content (i.e. a publisher may become a collaborator or viewer or have no access).
Publishers can assign / grant permissions for content that they either own or have been added as a collaborator for. Administrators can add themselves as collaborators to any content on the system. Depending on the content specific access settings, publishers and viewers may only have "viewer" access or even no access to the content.
The effect of the permissions granted depend on the type of content. Base role permissions are used for general access to the RStudio Connect dashboard although what is visible within the dashboard will be a result of the permissions granted to the user.
In general, the permissions available to a user follow the abilities outlined in the role descriptions. For example, a publisher who only has viewer rights would experience the permissions granted to the viewer role for a specific piece of content.
R Markdown Reports#
Access controls and user privileges apply to every public version of a report.
For example, if the default version of a report is accessible to
public versions will be accessible to
- Anonymous Visitors
Every version of a report has a unique URL (accessible by opening the content with 'Open Solo'). Reports must be listed for
Anyonefor the URL to be available to anonymous users.
"Viewers" have the ability to view a report through the Connect dashboard. They can discover and toggle between public versions of a report. They can email themselves the current version of a report. They can not see parameters for different versions of a report. They can see the distribution and schedule for public versions.
"Collaborators" have the privileges of Viewers and additionally can: view parameters for public versions, change parameters and run ad hoc reports, create new versions, schedule versions, setup distribution lists, and request reports to be refreshed. Collaborators can also create private versions that are not discoverable or accessible by any other user.
The publisher who published the content to the RStudio Connect server is considered the owner of the content. They have full control over all functionality associated with the content.
Shiny Applications & Plumber APIs#
"Collaborators" can change the runtime settings for Shiny applications and Plumber APIs.
Accounts can be either created / pre-provisioned or auto-registered. Details and capabilities differ by authentication provider. Please refer to the specific chapter for the product / provider you are integrating with.
Administrators may alter the usernames of existing users on the system regardless of the current authentication system. Users will still be able to access their deployed content and content that has been shared with them. If they have existing vanity URLs with their username incorporated, none of those will be altered. They will, of course, need to use the new username when logging in.
If the user has authenticated inside of the RStudio IDE, they will still be able to deploy using a previous connection; however, the IDE will continue displaying their old username during deployments. To minimize the risk of future ambiguity, we recommend that the user disconnect and reconnect their IDE to RStudio Connect so that the valid username is displayed.
You can prohibit a user from accessing RStudio Connect by "locking" their account. This control is available to administrative users when editing user profile information in the RStudio Connect dashboard.
Locked users are prohibited from signing into RStudio Connect, deploying content, and otherwise interacting with the service.
A locked account is not deleted and deployed content continues to be available. A non-personal report configured with scheduling and distribution will continue to execute according to its schedule. A locked user no longer receives scheduled content at their email address.
Content owned by a locked user can be deleted by a collaborator or by an administrative user. Each piece of deployed content must be deleted individually; there is no bulk removal.
A locked user can be subsequently unlocked. All their previously allowed abilities are immediately restored.
Locked users are not counted against the Named User quota on your RStudio Connect license.
Removing accounts from RStudio Connect is considered a last resort option.
Users are kept around so the content and groups they might own, as well as the historical and audit information associated with user is not left without a reference.
For these reasons locking accounts is still the preferred option.
If the decision is to remove the account, use the
usermanager CLI tool. The
removal process requires that the user does not own anything in RStudio
Connect. It's possible to transfer the user's assets to another user ahead of
the account removal. This transfer is also possible with the
The historical information will still refer to the removed user account. See the Historical Information section for details about what information is being tracked.
Once the user account is removed, the only place where the user information can still be found is in the audit logs. See the Audit Logs section for details.