Shiny Server Pro: Google Authentication Examples

This article is adapted from the Shiny Server Administrator's Guide for version 1.4.2.

Overview

Shiny Server Pro supports the ability to rely on Google for the management of your users using the auth_google setting. In this environment, users attempting to log in to your Shiny Server would be presented with a button asking them to log in via Google. If they grant access to your application, they will be returned to your Shiny Server presenting the email address associated with their Google account. At that point, this email address can be used to grant or restrict access to individual applications and locations.

There are three main steps to configuring Shiny Server Professional to use Google Authentication:

1. Create a Google Application

2. Configure Shiny Server

3. Implement Email Address Restrictions

Create a Google Application

Before you can use Google Authentication on your server, you must register an "application" with Google. This is the application that your users will be asked to "connect" to when logging in to your Shiny Server. To do this, you can visit Google's Developer's Console which, at the time of writing, is available at https://console.developers.google.com/.

You'll initially create a project then give it a name and ID. Under "APIs & auth" you'll find the "Credentials" section. There you have the ability to "Create new Client ID"; do that now. The type of application is a "Web application". For the "Authorized JavaScript Origins", you'll need to explicitly list any name a user might use to access your server including the domain name, port, and protocol. For instance, if you offer both HTTPS and HTTP access to your Shiny Server, you'll need to include both; if you have multiple domain names pointing to your server, you should include all of those domains; if you have servers running on multiple ports, you'll need to include them all explicitly here.

In the "Authorized redirect URI" field, you'll again need to provide all possible ways a user may be accessing your server, but append the string __login__/callback (note the doubleunderscores on either side of "login") to each URI.

For instance, if you have a server available at both example.org and example.net, supporting both HTTP and HTTPS, offering web services with or without a www. subdomain prefix, and using the standard ports (80 and 443, respectively), you would use the following origins:

• http://example.org
• http://www.example.org
• https://example.org
• https://www.example.org
• http://example.net
• http://www.example.net
• https://example.net
• https://www.example.net

And the Authorized redirect URIs would include:

• http://example.org/__login__/callback
• http://www.example.org/__login__/callback
• https://example.org/__login__/callback
• https://www.example.org/__login__/callback
• http://example.net/__login__/callback
• http://www.example.net/__login__/callback
• https://example.net/__login__/callback
• https://www.example.net/__login__/callback

You can then "Create" your Client ID.

You should see your new "Client ID for web application" listed once you have created your new Client ID. You can inspect to confirm that the Redirect URIs and Javascript Origins look correct (if not, you can click "Edit settings"). If they look correct, you should note the "Client ID" and "Client secret"; you'll enter these settings into your Shiny Server configuration file later.

At this point, you've created a Google application you'll be able to use to allow your users to login via Google on your Shiny Server. You can always add more details to your Google application here including an icon and more textual details.

Configure Shiny Server

After you have a Google application created, you can customize your Shiny Server configuration to instruct it to use Google for its authentication.  You can do so by editing your configuration file, /etc/shiny-server/shiny-server.conf, to add the auth_google directive at the top level. This setting first takes the Client ID, then the Client Secret you created in Google earlier, like so:

auth_google 12345.google.com ABCDEF;

Alternately, you can specify the absolute path to a file containing the client secret:

auth_google 12345.google.com /etc/shiny-server/ga-secret.txt;

With this configuration, Shiny Server would read the client secret in from the file stored at /etc/shiny-server/ga-secret.txt. Additionally, if the client secret is a path to a file rather than the secret itself, Shiny Server will retain root privileges, allowing you to tighten the security around the file containing your client secret to allow only the root user to read it.

Once this is set up properly, you can then add a required_user directive to your location definitions, to restrict access to particular applications if you like.  For example:

location /app1 {
  site_dir /srv/shiny-server/app1;
  required_user tina@example.com joe@example.com rose@example.com;
}

With this configuration, the /app1 application is only accessible to the specified three users.  When users access this resource, they will be prompted to login with Google. If their email is included in the required_user field associated with the resource they are trying to access, they will be let in. Otherwise, they will still be logged in as that user, but they will not be granted access to that resource.

Email Address Restrictions

By default, the Google authentication strategy will allow any user with a Google account to log in to your system. Though you can use required_user to restrict access to a resource, some organizations wish to allow only particular users to log in at all.  For such situations, we provide the ability to filter which email addresses will be authorized into your Shiny Server, regardless of what the individual application's required_user settings are.

To use this, add filters onto the auth_google setting in your configuration file. In the simplest form, you could add one filter to require that the email address the user is using with Google be of a particular form, such as "*@myorganization.org". This would allow any user who logged into Google with the email address that ended in @myorganization.org to log on to the server. Once logged on, the required_user filters would be applied as usual to control access to individual applications.

You can provide as many filters as you like on the auth_google directive and indicate whether email address matching that filter should be admitted (+) or rejected (-). If no sign is provided, it's assumed that the filter should be admitted (+). The filters will be applied one at a time, in the order provided, until the given email address matches one of your filters.  The first filter an email matches will be used to determine whether or not that email address should be allowed to log in to Shiny Server. If an email address matches none of the provided filters, it will be rejected.

A few examples may be helpful:

auth_google 12345.google.com ABCDEF "*";

The filter "*" will be interpreted as a positive filter, meaning any email address matching that filter (every possible email address) will be admitted. This is the default behavior if you don't provide any filters in the configuration file.

auth_google 12345.google.com ABCDEF "*@myorganization.org";

The filter "*@myorganization.org" will admit any user whose email address ends in @myorganization.org and reject any email address that does not.

auth_google 12345.google.com ABCDEF "-jim@example.org" "*@example.org";

In these filters, if the user kelly@example.org were attempting to access the server, the first filter would be checked and it would be found that kelly@example.org does not match the filter "jim@example.org", so it would continue on to the next filter. There it would be found that kelly@example.org does match the filter *@example.org, and because this filter is a positive filter ( + is default when no sign is provided), this user would be granted access to the system. However, a user john@gmail.com would not match the first filter or the second filter, so he would be denied access to the system, as he did not match any positive filter. Finally, the user jim@example.org would match the first filter, and because that filter is a negative filter, this user would be denied access to the system.

Shiny Server Pro supports a lightweight pattern-matching syntax. Specifically, use the * character to match any string of length 0 or more, the ? character will match any one character, and square brackets can be used to match against a set of characters such as [a-e] to match any character between a and e. All patterns are not case-sensitive.

Finally, it may be necessary to educate your users on the behavior of Single Sign On (SSO) systems like Google. Specifically, some users may not understand that logging out from a Shiny app will not log them out of Google. Currently, logging out of Google will also not log you out of Shiny Server. Rather, there is a one-time connection between the two systems at the moment the user logs in. From there on, their Google session and their Shiny Server session will be completely independent.