Re: [galaxy-dev] public datasets/histories with external auth

Shantanu Pavgi wrote: > > On Jun 28, 2011, at 2:15 PM, Nate Coraor wrote: > > Shantanu Pavgi wrote: > > I did a test by excluding following URLs from Apache-Shibboleth external authentication and it seems to be working: > - /datasets/ > - /u/<username>/h/<history-name> > - /static/ (css and javascript) > > Do I need to exclude any other URLs so that published histories and datasets can be accessed from remote sites without authentication? Also, will it offer read-only access to the galaxy interface? Does it expose any job submission, file-uploads or any other modification/execution operations using web interface? > > Hi Shantanu, > > These should be sufficient and would not give access to anything job or > tool related. However, since /datasets/ is exposed, this means that any > dataset with no roles associated with the access permission (i.e. a > "public" dataset) would be readable by anyone. Dataset IDs are encoded > so as not to be easily guessable, but relying on this is essentially > "security by obscurity." > > > Thanks for the reply Nate. We are able to view datasets over to UCSC site if we directly append /dataset URL as a query parameter to the main UCSC URL. But we discovered one more use case where datasets contained in a particular history have a different URL format for UCSC link. > > For example, you should be able to access following URL without authentication: > https://galaxy.uabgrid.uab.edu/history/list_shared?sort=-update_time&... > > Now if you click on dataset-1 and then click on 'display at UCSC main' then the resulting URL is as follows: > > https://galaxy.uabgrid.uab.edu/datasets/3423/display_at/ucsc_main?redirec... > > This link fails without authentication as we have exposed only /datasets URL pattern. I can manually insert /dataset URL for UCSC 'display_url', however it's not intuitive for end users. I am bit concerned about opening up "/root/display_as" URL pattern without knowing it's implications. I guess it doesn't expose any jobs or tools related access, but not sure about it. Any comments or suggestions? display_as is covered under "Display at UCSC": https://bitbucket.org/galaxy/galaxy-central/wiki/Config/ApacheProxy You can expose it just to UCSC or globally. Since you're already exposing /datasets/ globally, doing the same with /root/display_as is probably not much different. --nate > > > > Also, can we prevent particular galaxy-user from carrying out certain actions, e.g. running jobs, file uploads etc.? Since galaxy will create 'anonymous' user account based on the REMOTE_USER variable set for unauthenticated requests, I am wondering if such locked-down mode will be possible for a particular galaxy-user. > > This cannot be done from within Galaxy, but it shouldn't be necessary > since these actions are not exposed to the anonymous user. > > I think the user is not anonymous here as we have already written REMOTE_USER to 'anonymous' now. The galaxy receives this user as user-login/email as 'anonymous@mail.domain<mailto:'anonymous@mail.domain>'. > > Now we are opening up certain URL patterns to be accessed as 'anonymous@mail.domain<mailto:'anonymous@mail.domain>' user. These URL patterns include following formats as mentioned - /datasets, /history, /u/<username>/h<history-name>, and /static. In addition we may need to expose "/root/display_as" URL pattern as well. Rest of the site remains protected using real authentication. > So as long as above URL patterns don't expose any job submission, file uploads or other galaxy tools operations then we should be OK with it. Thoughts? > > -- > Thanks, > Shantanu. >