Thanks for pointing it out Nate. I had missed that in the docs.
--
Shantanu.
On Jun 30, 2011, at 8:51 AM, Nate Coraor wrote:
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.
>