Authentication and authorization

ShinyProxy has advanced authentication and authorization features. The different authentication backends allow users to log-in, while the various access control properties limits apps and features to certain users. Except for the simple authentication backend, ShinyProxy doesn’t maintain a list or a database of users. Therefore, the information about a user is only available when they log in. Every backend provides at least a username for each user. If configured, most backends can also provide a list of groups for the user. Instead of groups, some authentication providers uses roles, this is supported by ShinyProxy as they’re just handled as groups. Information about the user is only updated at the moment the user logs in (and only for that session). Therefore, if the information of the user changes, they have to logout and log-in before the information is updated.

In addition, ShinyProxy automatically sends information about the user to every app, allowing the app to perform its own authorization.

Users

Every user in ShinyProxy has a username. Most authentication backends in ShinyProxy, allow you to choose which field (sent by the authentication provider) is used as username. ShinyProxy assumes that a username (provided by the authentication provider) is unique. When disabling authentication, a unique username is automatically generated for each session. It depends on the authentication provider whether, during log-in, the username is case sensitive. The only exception is the simple authentication backend, which always handles user names as case insensitive. When comparing usernames during authorization, ShinyProxy handles these as case-sensitive. Using the proxy.username-case-sensitive property this can be changed to case-insensitive.

Groups

Users in ShinyProxy can be part of one or more groups. The group information is retrieved from the authentication provider. Similarly to the username, you can configure which field (sent by the authentication provider) to use for the group information. ShinyProxy converts the name of the groups to upper-case, making these case insensitive. In addition, the prefix ROLE_ is removed from any group name.

Access control for apps

ShinyProxy allows to limit access to an app. This is applied to all parts of ShinyProxy, such as the list of apps on the main page, the API and accessing the app directly. ShinyProxy supports the following properties for access control:

Note: it’s possible to combine the first three access control options. In this case OR logic is applied between the different options. In other words, this means that at least one of the access control options must give a positive result before the user is granted access to the app. The access-strict-expression property is always evaluated and must always return true, even if other access control settings allow the user to access the app. This is useful to combine filtering apps (e.g. by server name) and regular access control.

Using access control within an app

Limiting who can use an app is already useful, but sometimes you need more fine-grained access control inside an app. For example, to limit access to confidential data to specific users. To achieve this, ShinyProxy sends the username and groups of the current user to every app using environment variables:

  • SHINYPROXY_USERNAME: the username of the user
  • SHINYPROXY_USERGROUPS: the groups of the user as a comma-separated value
  • SHINYPROXY_OIDC_ACCESS_TOKEN: the access token of the user (only when using OIDC)

When using container pre-initialization and sharing the environments variable can’t be used, since the container is created before it’s assigned to a user (and the container is shared among multiple users). Therefore, ShinyProxy also sends the information as HTTP headers:

  • X-SP-UserId: the username of the user
  • X-SP-UserGroups: the groups of the user as a comma-separated value

These headers are automatically added to every HTTP request sent to the app.

See the example code on how to use both methods in Shiny. It’s also possible to send additional user information as environment variables or headers.

Finally, using SpEL expressions it’s possible to have different configuration values for different users. For example, by using a SpEL expression in the container-memory-request property, you can assign different amounts of memory depending on the username or groups of a user.

General access control

Similarly to limiting the access to specific apps, ShinyProxy allows limiting access to specific features.

Access to the admin panel can be limited to specific groups or specific users.

The Kubernetes pod patches and additional manifests features allow to only apply patches or manifests for specific users. This uses the exact same access control as apps, using groups, users, or an expression.

Finally, the parameters feature has full support for access control, limiting the use of specific parameters to specific users. Again, this uses the same access control method as apps, allowing to specify groups, users, or an expression.