Hi Alex, I've been trying to do something similar. There are no doubt others on this list who can offer more official answers than mine, but I'm happy to share my experience so far: 1) First of all, do make sure to read through http://wiki.galaxyproject.org/Admin/Config/Performance/ProductionServer. It's the best starting point for customizing your local production deployment. 2) For AD authentication, it is indeed possible to kick that off to the Apache proxy to handle. I ended up opting out of using it because of some anomalies and my lack of AD knowledge, and frankly I think there are some UX disadvantages to using apache's generic authentication prompt. Personally I'd like to see AD or other authentication handling be served directly by the Galaxy backend (same login prompt and everything), but that's just my personal taste. Applicable documentation: http://wiki.galaxyproject.org/Admin/Config/Apache%20Proxy 3) I think there are a couple ways to go about this, but none of them are direct. Actually mounting the shares will probably be the most difficult part, especially if you need to take permissions into account. On the AD side, you'll want to first verify that the shared drive is mountable by the OS of your Galaxy server. Depending on how the share is configured (AD file permissions vs linux file permissions), you might have some trouble matching permissions on, say, a linux server. Assuming you can mount to your Galaxy server, I personally think the easiest thing to do would be to mount not individual user shares but rather a single share with individual user directories. You could potentially take advantage of Galaxy's FTP Upload functionality (http://wiki.galaxyproject.org/Admin/Config/Upload%20via%20FTP) at this point, sans the ftp server. Let's say you mounted the AD governed single point share to /mnt/ad-drive. You could set 'ftp_upload_dir=/mnt/ad-drive' in Galaxy's universe_wsgi.ini file. The trick here would be to get Galaxy to map user directories under /mnt/ad-drive in a manner that Galaxy's FTP interface understands. To do it Galaxy's way, you would want user directories to appear as their full e-mail address as registered with Galaxy; so, for example "alexander.kurze@bioch.ox.ac.uk" would appear on the share as literally "/mnt/ad-drive/alexander.kurze@bioch.ox.ac.uk". The fact that users would be registering on galaxy with their AD credentials would help keep that system in sync. With the ftp_upload_dir option configured, user@bioch.ox.ac.uk would see an extra option in the Import Data interface to directly import data files from /mnt/ad-drive/user@bioch.ox.ac.uk. As far as exporting data from their Galaxy account to the shared drive, I've come across a couple tools in the Galaxy ToolShed that do exactly that. Alternatively, I don't know if your server is sitting in front of a cluster, but you could always go down the route of running jobs as the actual system user, assuming a system configuration where system users are AD users. See: http://wiki.galaxyproject.org/Admin/Config/Performance/Cluster Hope some of that is helpful. -- Andrew Stewart Office of Research Information Services (ORIS), Office of the Chief Information Officer (OCIO), Smithsonian Institution 202-505-3633 On 12/1/13 12:00 PM, "galaxy-dev-request@lists.bx.psu.edu" <galaxy-dev-request@lists.bx.psu.edu> wrote:
Message: 1 Date: Thu, 28 Nov 2013 14:06:58 +0000 From: Alexander Kurze <alexander.kurze@bioch.ox.ac.uk> To: galaxy-dev <galaxy-dev@bx.psu.edu> Subject: [galaxy-dev] Active Directory Message-ID: <CABaBi0cTcQvDfLwJ2WLJG0FDBkWD2LALnEs6yRqFVwFya5K=Rw@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1"
Hi there,
I have a server set up of galaxy. I would like to have a system setup where people can login via their active directory name and then use their mounted share drive to download processed data from the galaxy server.
I saw that it is possible via apache to login through the AD, but will the AD also mount the share drives? If yes, is there a wrapper that allows to download Galaxy Histories onto the shared drive?
Alex
participants (1)
-
Stewart, Andrew