User Management¶

User Roles¶

Every RStudio Connect user account is configured with a role that controls their default capabilities on the system. Data scientists, analysts and others working in R will most likely want "publisher" accounts. Other users are likely to need only "viewer" accounts.

The Authorization.DefaultUserRole property specifies the role for new accounts and defaults to viewer. Authorization.DefaultUserRole may be either viewer or publisher; new accounts are not permitted to automatically have the administrator role. For all authentication providers, the first user is always created as administrator.

Note: There are no restrictions regarding roles for the users created via the Connect Server API.

Administrator: 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. The specific capabilities of an administrator are documented here.
Publisher: Accounts with a "publisher" role are allowed to deploy content into RStudio Connect. They can also help manage another user's content when made a "collaborator" of that content.
Viewer: "Viewer" accounts can be added as a viewer to specific content. They can discover that content through the RStudio Connect dashboard and see its settings. Viewers can also email themselves copies of documents they are permitted to see.
Anonymous: An anonymous visitor to RStudio Connect who is not authenticated with the system can view content that has been marked as viewable by "Anyone".

Note: Any logged-in user can list all the other existing users. To limit what viewers can see use Authorization.ViewersCanOnlySeeThemselves.

Automatic User Role Mapping¶

Your 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.

When users login using LDAP, SAML, OAuth2 (OpenID) or Proxied authentication, RStudio Connect offers ways to map that user information to valid user roles.

Using User Profile Roles¶

Use the configuration option Authorization.UserRoleMapping to enable user role mapping.

The following configuration options should also be defined in your authentication provider of choice to receive role information as part of the user profile:

Note: User roles can be used directly from your authentication provider without the need of mapping values as long as it only returns the values of viewer, publisher and administrator to define roles in RStudio Connect.

When mapping is enabled, each role can be mapped to one or more values specific to your organization using the configuration options Authorization.ViewerRoleMapping, Authorization.PublisherRoleMapping, and Authorization.AdministratorRoleMapping.

In the following example the authentication provider returns department names:

; /etc/rstudio-connect/rstudio-connect.gcfg
[Authorization]
UserRoleMapping = true
ViewerRoleMapping = HR
ViewerRoleMapping = Marketing
PublisherRoleMapping = Engineering
AdministratorRoleMapping = IT

Using Group Memberships¶

Use the configuration option Authorization.UserRoleGroupMapping to enable user role mapping via groups.

Note: When group mapping is enabled, configuration options to receive roles from the authentication provider as part of the user profile information will be ignored and RStudio Connect will fail to start if Authorization.UserRoleMapping is also enabled.

When enabled, the configuration options Authorization.ViewerRoleMapping, Authorization.PublisherRoleMapping, and Authorization.ViewerRoleMapping will refer to groups.

In the following example group names are used. Viewer mapping is purposely left out so that the remaining of the users will be assigned the based on the option Authorization.DefaultUserRole which defaults to viewer.

; /etc/rstudio-connect/rstudio-connect.gcfg
[Authorization]
UserRoleGroupMapping = true
PublisherRoleMapping = Developers
AdministratorRoleMapping = Dev-Leaders
AdministratorRoleMapping = IT-Administrators

Note: The mapped values should refer to groups in the way your authentication provider sends them. Normally this refers to the group names but it can also refer to a group's unique identifier such as a GUID (i.e. Azure) or DNs (i.e. LDAP). Please refer to your specific authentication provider section for details.

Multiple User Role Mappings¶

When there are multiple matches between the configured mapping and the user or group information sent by the authentication provider, the role with the most privileges is selected. This behavior makes it easy to promote users to a new role.

Note: If there are concerns about security, a more restrictive behavior can be used in these scenarios with the configuration option Authorization.UserRoleMappingRestrictive. When enabled, it will cause the least privileged role to be selected.

User Provisioning¶

How a user gets created in RStudio Connect depends on the capabilities offered by the configured authentication provider. See the Authentication section for more details.

Password (Built-in) Authentication¶

Note: Password authentication works with limited convenience without email settings. See Email Sending.

The users can be created by an administrator or they can register themselves through the RStudio Connect dashboard. The Connect Server API can also be used to create users ahead of the first login.

The users created by an administrator or via Connect Server API without a password will receive an email confirmation which should be used to configure a password.

Existing user accounts can reset their passwords through the Connect login page or an RStudio Connect administrator can make this request from the user's profile.

Usernames¶

Usernames must be unique for Password Authentication. Those usernames are chosen by the users themselves or by an administrator.

Self Registration¶

When using password authentication, users can self-register by clicking the "Sign Up" button on the login page. Self-registered accounts will be created with the role specified in the Authorization.DefaultUserRole property (see User Roles).

If you wish to disable self-registration, please give the configuration setting Password.SelfRegistration a value of false.

; /etc/rstudio-connect/rstudio-connect.gcfg
[Password]
SelfRegistration = false

When self-registration is disabled, the first account (the administrator) is still created using self-registration. All other accounts must be created by an administrator.

OAuth2 (OpenID Connect)¶

OAuth2 users are created in RStudio Connect upon the first successful login attempt. OAuth2.RegisterOnFirstLogin can be used to disable this behavior.

; /etc/rstudio-connect/rstudio-connect.gcfg
[OAuth2]
RegisterOnFirstLogin = false

If registration through login is disabled, users must either be a member of an allowed group or added as viewers or collaborators to content in order to be able to login.

The authentication will happen entirely in the OpenID Connect OP which once completed will return the remote user information to RStudio Connect.

Note: User search support is limited to the Google vendor only. See the OAuth2 section.

New users can also be created ahead of their first login by searching based on their email or name and then associating the remote user found in the results with some content as either a viewer or collaborator.

Note: New users can only be selected as collaborators when Authorization.DefaultUserRole is configured as publisher or when User Role Mapping is configured.

The Connect Server API can be used to create OAuth2 users. This option enables associating users with content ahead of their first login attempt.

Note: For Google, prior to adding the user to RStudio Connect via the Connect Server API, a separate API call for retrieving the user profile from the provider is needed. For other vendors, a unique identifier that matches the one sent by the OpenID OP (sub claim by default) must be provided to create users via Connect Server API.

Usernames¶

Usernames must be unique for OAuth2 when using Google (default). Initially, usernames are generated based on the user's email address during the first login to RStudio Connect. Duplicate or prohibited usernames have a sequence number suffix added. These usernames can later be modified by the users themselves or by an administrator as long as the usernames remain unique. RStudio Connect will refuse to change the username otherwise.

For all other OpenID Connect vendors, usernames are defined externally by the authentication provider. They are not guaranteed to be unique.

Note: The lack of uniqueness makes difficult for content hosted by RStudio Connect to rely on the usernames passed in the RStudio-Connect-Credentials header. In this case the option Authorization.ContentCredentialsUseGUID should be enabled so that content will receive the globally unique identifiers assigned by RStudio Connect. These are the same identifiers to used with the Connect Server API.

Note: The RStudio Studio IDE does not support duplicate usernames when publishing to the same RStudio Connect host. However, it is unlikely that two users with the same usernames will be sharing the same IDE account or workstation.

LDAP or Active Directory¶

LDAP or Active Directory users are created in RStudio Connect upon the first successful login attempt. LDAP.RegisterOnFirstLogin can be used to disable this behavior.

; /etc/rstudio-connect/rstudio-connect.gcfg
[LDAP "corporate LDAP"]
RegisterOnFirstLogin = false

If registration through login is disabled, users must be added as viewers or collaborators to content in order to be able to login.

Note: To restrict which users can login, see the setting LDAP.PermittedLoginGroup.

RStudio Connect will forward the entered LDAP credentials to the LDAP or Active Directory server which once authenticated will return the remote users information.

Note: User search support for LDAP requires bind credentials or anonymous bind. See the LDAP section.

New users can also be created ahead of their first login by searching based on their email or name and then associating the remote user found in the results with some content as either a viewer or collaborator.

Note: New users can only be selected as collaborators when Authorization.DefaultUserRole is configured as publisher or when User Role Mapping is configured.

The Connect Server API can be used to create LDAP users. This option enables associating users with content ahead of their first login attempt.

Note: Prior to adding the user to RStudio Connect via the Connect Server API, a separate API call for retrieving the user profile from the provider is needed.

Usernames¶

Usernames in LDAP do not need to be unique. The user identity in LDAP is determined via the configured LDAP.UniqueIdAttribute and users with the same username are differentiated via their personal passwords. Duplicate usernames are a reality of large LDAP or Active Directory deployments with multiple servers, which implies multiple LDAP connections in RStudio Connect.

Note: Active Directory global catalog configurations can also return duplicate usernames. However, that happens over a single LDAP connection which means a search for a username may return multiple hits. This configuration is not currently supported by RStudio Connect. The lack of uniqueness makes it difficult for content hosted by RStudio Connect to rely on the usernames passed in the RStudio-Connect-Credentials header. In this case the option Authorization.ContentCredentialsUseGUID should be enabled so that content will receive the globally unique identifiers assigned by RStudio Connect. These are the same identifiers used with the Connect Server API.

Note: The RStudio Studio IDE does not support duplicate usernames when publishing to the same RStudio Connect host. However, it is unlikely that two users with the same usernames will be sharing the same IDE account or workstation.

SAML¶

SAML users are created in RStudio Connect upon the first successful login attempt. SAML.RegisterOnFirstLogin can be used to disable this behavior.

; /etc/rstudio-connect/rstudio-connect.gcfg
[SAML]
RegisterOnFirstLogin = false

User fields which are mapped from SAML assertion attributes are updated (if they change) on all subsequent successful logins.

The actual authentication will happen entirely in the SAML Identity Provider that RStudio Connect is configured to talk with. See the SAML section for details.

Users are uniquely identified by their Unique ID in the IdP system. If RStudio Connect is presented with a Unique ID it has never seen, it will create a new user.

The Connect Server API can be used to create SAML users. For this to work correctly, the user's information must be obtained from the IdP with the correct Unique ID and then provided to the RStudio Connect Server API. This enables associating users with content ahead of their first login attempt.

Note: RStudio Connect has no facility for retrieving user data from a SAML IdP; some other means, provided by the IdP, must be used.

Usernames¶

Usernames in SAML authentication may or may not be unique depending on the configuration. This flexibility exists to adapt to the various authentication mechanisms that could be driving the SAML authentication.

By default, usernames are not unique in SAML. That's because the user identity is determined based on the SAML.UniqueIDAttribute.

Note: The lack of uniqueness makes it difficult for content hosted by RStudio Connect to rely on the usernames passed in the RStudio-Connect-Credentials header. In this case the option Authorization.ContentCredentialsUseGUID should be enabled so that content will receive the globally unique identifiers assigned by RStudio Connect. These are the same identifiers used with the Connect Server API.

Note: The RStudio Studio IDE does not support duplicate usernames when publishing to the same RStudio Connect host. However, it is unlikely that two users with the same usernames will be sharing the same IDE account or workstation.

There are situations where the username itself is not provided by SAML or the authentication mechanism behind it. In this case it's possible to generate a unique username based on the user's email address during the first login to RStudio Connect. Duplicate or prohibited usernames have a sequence number suffix added. To use this functionality the setting SAML.UsernameAttribute should be forced to have a blank value ("") and the header which contains the user's email must be configured in the setting SAML.EmailAttribute.

Note: The setting SAML.IdPAttributeProfile will override the individual attribute settings. Make sure this setting is not defined.

These generated usernames can later be modified by the users themselves or by an administrator as long as they remain unique. RStudio Connect will refuse to change the username otherwise.

Note: Switching between configurations where duplicate usernames are possible to one where the usernames are unique is strongly discouraged. If such change is necessary, be sure to make usernames unique by using the usermanager CLI tool before restarting RStudio Connect with the new configuration. See the User Management CLI appendix for more information.

Proxied Authentication¶

Proxied authentication will create users in RStudio Connect upon the first successful login attempt. ProxyAuth.RegisterOnFirstLogin can be used to disable this behavior.

; /etc/rstudio-connect/rstudio-connect.gcfg
[ProxyAuth]
RegisterOnFirstLogin = false

If registration through login is disabled, users must first be created via the Connect API in order to be able to login.

The authentication happens entirely in the Proxy placed in front of RStudio Connect which expects to receive from the former a HTTP header containing the username of the authenticated remote user account.

The Connect Server API can be used to create Proxy users. This option enables associating users with content ahead of their first login attempt.

Note: Users created via the API must match exactly the identifier expected to be received through the authentication proxy. By default, this identifier is the username, but it's possible to employ a separate unique identifier. See the Proxied Authentication section.

Usernames¶

Usernames in proxied authentication may or may not be unique depending on the configuration. This flexibility exists to adapt to the various authentication mechanisms that could be driving the proxied authentication.

By default, usernames are the user identity and therefore they are unique and immutable. Which means changes to the username will result in new user created in RStudio Connect.

If the proxy is able to provide an alternative user identity, then then settings ProxyAuth.UniqueIdHeader should be configured. In this situation usernames don't need to be unique.

Note: The lack of uniqueness makes it difficult for content hosted by RStudio Connect to rely on the usernames passed in the RStudio-Connect-Credentials header. In this case the option Authorization.ContentCredentialsUseGUID should be enabled so that content will receive the globally unique identifiers assigned by RStudio Connect. These are the same identifiers used with the Connect Server API.

Note: The RStudio Studio IDE does not support duplicate usernames when publishing to the same RStudio Connect host. However, it is unlikely that two users with the same usernames will be sharing the same IDE account or workstation.

Finally, there are situations where the username itself is not provided by the proxy or the authentication mechanism behind it. In this case it's possible to generate a unique username based on the user's email address during the first login to RStudio Connect. Duplicate or prohibited usernames have a sequence number suffix added. To use this functionality the setting ProxyAuth.UsernameHeader should be forced to have a blank value ("") and the header which contains the user's email must be configured in the setting ProxyAuth.EmailHeader.

These generated usernames can later be modified by the users themselves or by an administrator as long as they remain unique. RStudio Connect will refuse to change the username otherwise.

Note: Switching between configurations where duplicate usernames are possible to one where the usernames are unique is strongly discouraged. If such change is necessary, be sure to make usernames unique by using the usermanager CLI tool before restarting RStudio Connect with the new configuration. See the User Management CLI appendix for more information.

PAM¶

PAM authentication will create users in RStudio Connect upon the first successful login attempt. PAM.RegisterOnFirstLogin can be used to disable this behavior.

; /etc/rstudio-connect/rstudio-connect.gcfg
[PAM]
RegisterOnFirstLogin = false

If registration through login is disabled, users must first be created via the Connect API in order to be able to login.

PAM authentication relies on local Unix accounts. Users must login to RStudio Connect with their Unix credentials which is authenticated by the Linux system hosting Connect. Due to this constraint, PAM usernames are case-sensitive.

The Connect Server API can be used to create PAM users. This option enables associating users with content ahead of their first login attempt.

Note: The username is the user's unique identification in Connect. Users created via the API must match exactly the username for the respective Unix user.

Usernames¶

Usernames must be unique for PAM. The username is the user identity and it is tied to the respective Linux account. Changes to the Linux account usernames are not supported and will result in a new user created in RStudio Connect.

User Permissions¶

Administrators and Publishers can be assigned permissions for content published to RStudio Connect.

All Content¶

Anonymous Visitors: Anonymous users can access content listed for Anyone. Anonymous viewers access content through direct URLs and will not have any view into Connect.
Viewers: "Viewers" can sign into the Connect dashboard and discover and access content listed for Anyone, All users - login required, and content for which they are granted access. Viewers can also see all users and groups in RStudio Connect. Use Authorization.ViewersCanOnlySeeThemselves if more privacy is needed.
Collaborators: "Collaborators" can change access controls and add Viewers and other Collaborators. It's possible to allow collaborators to set custom "vanity" URLs with Authorization.PublishersCanManageVanities. Please note that these custom URLs set by collaborators must not being with any existing username, for security reasons. Only Administrators have that privilege.
Administrators: "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 RunAs user. Administrators and the original content owner can delete 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 Anyone, all public versions will be accessible to Anyone.

Anonymous Visitors: Every version of a report has a unique URL (accessible by opening the content with 'Open Solo'). Reports must be listed for Anyone for the URL to be available to anonymous users.
Viewers: "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: "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.

Shiny Applications & Plumber APIs¶

Collaborators: "Collaborators" can change the runtime settings for Shiny applications and Plumber APIs.

Administrator Capabilities¶

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 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 an error message 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.

Locked Accounts¶

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.

Your RStudio Connect Software License only allows this feature to permanently terminate access for a named user. If you need to purchase additional users, please contact sales@rstudio.com.

Username Requirements¶

Connect's username requirements vary depending upon the authentication provider. Please see the Username Requirements section for more information.

User Renaming¶

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.

Changing Authentication Provider¶

There are circumstances where the type of authentication provider must be changed. See the Changing Authentication Provider section for details.

Removing Accounts¶

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 usermanager.

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.

Command-Line Interface¶

Connect includes a usermanager command for some basic user management tasks. This utility helps you list users and modify their attributes. This can be helpful in the event that no one can access a Connect administrative user account.

Additionally, you can transfer ownership of content and groups between users as well as memberships to groups, permissions to content, content subscriptions and, under certain circumstances, even API keys. It's also possible to remove users that are not owners of any content or groups in RStudio Connect.

The usermanager can adjust the Unique IDs of users in case this identification has been modified in the configured authentication provider or after switching between providers.

See the User Management CLI appendix for more information on using the usermanager CLI to manage users.