wiki:Galaxy
Last modified 5 years ago Last modified on 03/02/12 12:15:40

Galaxy

Galaxy is a self-contained web application that uses built in python-based web server to serve its content (http://docs.uabgrid.uab.edu/wiki/Galaxy#Developers).

Galaxy development notes

Galaxy and Shibboleth Notes

Hooking applications into our system environment requires configuring them to trust the authentication subsystem. That is, configuring authentication external to the application. The application trusts the system environment to hand this and tell the application about the user.

For web applications this means configuring Apache to handle the authentication, setting REMOTE_USER (and potentially other headers), and having the application rely on REMOTE_USER to determine the current user and, ideally, carry out any necessary account creation steps automatically. We're following a standard systems philosophy. The application provides a service, it doesn't try to duplicate logic already handled by the system.

Galaxy supports REMOTE_USER and automatically creates accounts for new users https://bitbucket.org/galaxy/galaxy-central/wiki/Config/ApacheProxy. The only configuration required in the application is to edit universe_wsgi.ini and set

use_remote_user = True

Galaxy assumes usernames are SMTP addresses. In our default configuration user names are eduPersonPrinicpleNames (ePPN) not email addresses. For UAB people, we can fudge this since all advertised ePPNs are match an email address in the @uab.edu domain. Therefore, we don't need to set remote_user_maildomain in Galaxy.

The builtin python web server for Galaxy is not very feature rich and relies on Apache for any kind of advanced confguration, this includes handling external authentication. The recommended configuration is to configure an HTTP proxy connection between Apache on a standard web port and the default python web server on 8080 via localhost HTTP proxy loop-back.

This is fine, but usually when Apache handles authentication it sets REMOTE_USER as part of the CGI environment. HTTP connections don't ordinarily convey user information in an HTTP header, so mapping REMOTE_USER onto the back-end HTTP proxy communication channel takes a few extra steps.

The ApacheProxy steps document a workable solution. We ran into problems getting our rewrite rules to fire and populate a variable that can carry the current user name. Shibboleth is configured correctly and we see the full header in a test phpinfo() function. We followed the suggestion from the shib-user list but still couldn't get the RewriteCond?+RewriteRule? combo to extract the ePPN from the shibboleth headers.

This appears to be an issue with the order of the rewrite rule calls on the dev box and is being investigated.

Security concerns with shibboleth-to-proxy configurations

Using a proxy connection on the backend takes us out of the realm of reliable trust relationships between the identity provider and service provider and puts the burden of maintain security on the web application. Galaxy correctly denies access when no REMOTE_USER is set but this is pretty suceptable to misconfiguration and will need to be controlled well in a production configuration. The NativeSPSpoofChecking provides some hints.