Upstream Authentication

Overview

question Questions
  • How can I connect Galaxy with CAS, SAML, etc.
objectives Objectives
  • be familiar with configuring Galaxy to use an upstream (proxy) authentication provider
  • be able to log in to your Galaxy server with a file-configured user.
requirements Requirements

time Time estimation: 30 minutes

Overview

For this exercise we will use a basic password file method for authenticating - this is probably not a very useful method in production, but it demonstrates how the proxy server can be configured to provide the correct header to Galaxy, and how Galaxy integrates with upstream authentication providers. This same method can be used with NGINX and Apache modules for CAS or SAML authentication.

Agenda

  1. Configuring Authentication
  2. Testing
  3. API access
  4. Reverting

Configuring Authentication

hands_on Hands-on: Configuring everything

  1. Edit your galaxyservers group variables file and update the main location block defined for serving galaxy. Add the parameters:
    • auth_basic galaxy;
    • auth_basic_user_file /etc/nginx/passwd;
    • uwsgi_param HTTP_REMOTE_USER $reomte_user;

    It should look like:

        location / {
            uwsgi_pass           127.0.0.1:8080;
            uwsgi_param          UWSGI_SCHEME $scheme;
            include              uwsgi_params;
            auth_basic           galaxy;
            auth_basic_user_file /etc/nginx/passwd;
            uwsgi_param          HTTP_REMOTE_USER $remote_user;
            uwsgi_param          HTTP_GX_SECRET SOME_SECRET_STRING;
        }
    

    auth_basic enables validation of username and password using the “HTTP Basic Authentication” protocol. Its value galaxy is used as a realm name to be displayed to the user when prompting for credentials. auth_basic_user_file specifies the file that keeps usernames and passwords. uwsgi_param adds HTTP_REMOTE_USER to the special variables passed by nginx to uwsgi, with value $remote_user, which is a nginx embedded variable containing the username supplied with the Basic authentication.

    GX_SECRET is added as a header for security purposes, to prevent any other users on the system impersonating nginx and sending requests to Galaxy. NGINX and other webservers like Apache will strip any user-sent REMOTE_USER headers, as that header defines the authenticated user. If you can talk directly to Galaxy (e.g. via curl) and provide the REMOTE_USER header, you can impersonate any other use. While having Galaxy listen on 127.0.0.1 prevents any requests from outside of the system reaching Galaxy, anyone on the system can still send requests to that port. Here you can choose to switch to a unix socket with permissions only permitting Galaxy and Nginx to connect. For using sockets, we ins

  2. Add a pre_task using the pip module which installs the library passlib, which is required for htpasswd.

    Add a pre_task using the htpasswd module which sets up a password file in /etc/nginx/passwd, with owner and group set to root, and a name and password, and a mode of 0640.

    question Question

    How does your final configuration look?

    solution Solution

    - pip:
        name: passlib
    - htpasswd:
        path: /etc/nginx/passwd
        name: helena                    # Pick a username
        password: 'squeamish ossifrage' # and a password
        owner: www-data # nginx on centos
        group: root
        mode: 0640
    
  3. Galaxy needs to be instructed to expect authentication to come from the upstream proxy. In order to do this, set the following two options in your Galaxy group variables:

    ...
    galaxy_config:
      galaxy:
        ...
        use_remote_user: true
        remote_user_maildomain: ""
        remote_user_secret: SOME_SECRET_STRING
    

    Set the remote_user_maildomain option to the appropriate domain name for your site.

  4. Run the playbook

comment Access denied

If you see this message, it is because nginx is not correctly sending the REMOTE_USER or the GX_SECRET values.

access denied message

Testing

You should now be presented with a password dialog when attempting to load the Galaxy UI.

hands_on Hands-on: Testing

  1. Log in using the username and password you provided when creating the passwd file. If your username and the value of remote_user_maildomain match an existing user, you will be logged in to that account. If not, a new account will be created for that user.

  2. Click on the “User” menu at the top, to see how the username appears.

  3. Note that some user features are not available when remote user support is enabled.

    Try logging out by selecting User -> Logout. You will discover that when returning to the user interface, you are still logged in. This is because Galaxy has no way of logging you out of the proxy’s authentication system. Instead, you should set remote_user_logout_href in galaxy.ini to point to the URL of your authentication system’s logout page.

API access

If you wish your Galaxy to be accessible to command line clients (e.g. bioblend, blend4j, parsec), you will need to add an exception for authentication on the API. Galaxy will still be secure and protected, but non-browser access will be permitted with an API key.

location /api/ {
    satisfy any;
    allow all;
}

Reverting

We don’t want to leave Galaxy this way for the rest of our workshop.

hands_on Hands-on: Reverting the changes

  1. Edit your group variables file and comment out:

    • the NGINX changes
    • use_remote_user: true
  2. Run the playbook

keypoints Key points

  • Remote auth is not complex to set up and can help you meet institutional requirements

congratulations Congratulations on successfully completing this tutorial!