12 User Management

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

12.2 User Provisioning

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

12.2.1 Password (Built-in) Authentication

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

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.

12.2.1.1 Usernames

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

12.2.1.2 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 12.1).

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.

12.2.2 OAuth2 (Google Apps with 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 Google Auth engine which once completed will return the remote user information to RStudio Connect.

Note: User search support is conditional to your Google Auth infrastructure. See 11.8

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.

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

12.2.2.1 Usernames

Usernames must be unique for OAuth2. 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.

12.2.3 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 11.6

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

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.

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

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.

12.2.4 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 section 11.7 for details on how to do that.

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.

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

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.

12.2.4.1 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 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 item B.3 for more information.

12.2.5 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 11.10.

12.2.5.1 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 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 item B.3 for more information.

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

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.

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

12.3 User Permissions

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

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

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

12.3.3 Shiny Applications & Plumber APIs

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

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

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

12.6 Username Requirements

Connect’s username requirements vary depending upon the authentication provider. Please see 11.3 for more information on username requirements.

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

12.8 Changing Authentication Provider

There are circumstances where the type of authentication provider must be changed. See section 11.1 for details on how to do this.

12.9 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 section 20 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 section 9.3 for details.

12.10 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 Appendix B for more information on using the usermanager CLI to manage users.