Re: [galaxy-dev] public datasets/histories with external auth
Hi again,
I just realized that my setup is not going to work at all and does that
exact thing you just mentioned, even if you are logged in it will set the
REMOTE_USER to anonymous when you click on any /datasets URL. This causes
some strange Galaxy history behavior!
oops,
Leandro
On Fri, Jul 1, 2011 at 10:36 AM, Leandro Hermida wrote:
> Hi Shantanu,
>
> Thank you for your update, I've done my config a little differently and it
> appears to work just the same. The relevant part looks like this:
>
>
>## ActiveDirectory authentication and authorization
>AuthType Basic
>AuthBasicProvider ldap
>AuthName "R&D Galaxy Testing/QA Server"
>AuthLDAPURL "ldap://my.server.com:389/OU=Users &
> Workstations,DC=domain,DC=com?sAMAccountName?sub?(|(objectClass=person)(objectClass=group))"
>
># ...more AuthLDAP directives here...
>
>RequestHeader set REMOTE_USER %{AUTHENTICATE_sAMAccountName}e
>
>
>
>Order Allow,Deny
>Allow from All
>Satisfy Any
>
>RequestHeader set REMOTE_USER "anonymous"
>
>
>## Static content and reverse proxy
>RewriteEngine On
>RewriteRule ^/static/style/(.*)
> /path/to/galaxy/galaxy_dist/static/june_2007_style/blue/$1 [L]
>RewriteRule ^/static/scripts/(.*)
> /path/to/galaxy/galaxy_dist/static/scripts/packed/$1 [L]
>RewriteRule ^/static/(.*) /path/to/galaxy/galaxy_dist/static/$1 [L]
>RewriteRule ^/favicon.ico /path/to/galaxy/galaxy_dist/static/favicon.ico
> [L]
>RewriteRule ^/robots.txt /path/to/galaxy/galaxy_dist/static/robots.txt
> [L]
>RewriteRule ^(.*) http://galaxy.server.hostname:8080 [P]
>
>
>
>
> On Fri, Jul 1, 2011 at 12:13 AM, Shantanu Pavgi wrote:
> >
> > On Jun 30, 2011, at 6:34 AM, Leandro Hermida wrote:
> >
> >> Hi Nate and Shantanu,
> >>
> >> Thanks so much for the clear guidance, this works and sorry I didn't
> >> read the Apache docs properly
> >>
> >> best,
> >> Leandro
> >>
> >> On Thu, Jun 30, 2011 at 6:14 AM, Shantanu Pavgi wrote:
> >>>
> >>> On Jun 29, 2011, at 12:21 PM, Nate Coraor wrote:
> >>>
> >>> Leandro Hermida wrote:
> >>>
> >>> Hi Shantanu,
> >>>
> >>> In your Apache configuration exactly how did you set up an anonymous
> >>>
> >>> REMOTE_USER just for specific locations like the /datasets/ path? I'm
> just
> >>>
> >>> looking at the Apache docs and the RequestHeader directive has a
> context of
> >>>
> >>> the entire VirtualHost and cannot be put into a Location container so
> I'm
> >>>
> >>> not sure how to do it.
> >>>
> >>> Hi Leandro,
> >>>
> >>> See the optional 'env=' argument and docs on the same for ways to make
> >>> RequestHeader conditional:
> >>>
> >>>
> http://httpd.apache.org/docs/current/mod/mod_headers.html#requestheader
> >>>
> >>> So, depending on the path accessed, you should be able to have
> >>> mod_rewrite set an environment variable specifying which REMOTE_USER
> >>> (real username or fake anonymouse user) should be set.
> >>>
> >>> You could also just set it as the anonymous user to start with and then
> >>> use 'RequestHeader set' to overwrite it with the real username in the
> >>> case that a real username is available.
> >>>
> >>> This is all just from glancing at the docs, though, I have not tried
> any
> >>> of it out, and this sort of Apache trickery is always difficult to get
> >>> right.
> >>>
> >>> --nate
> >>>
> >>>
> >>>
> >>> Leandro,
> >>> The RequestHeader has a context of 'directory' as well, which includes
> >>> , , , and containers [1]. So you
> should
> >>> be able to use it in Location directive.
> >>> Following is a configuration snippet related to what Nate described in
> his
> >>> earlier response. We are setting REMOTE_USER variable to anonymous when
> it's
> >>> not set/empty.
> >>>
> >>> AuthType shibboleth
> >>> ShibRequireSession off
> >>> Require shibboleth
> >>> RewriteCond %{LA-U:REMOTE_USER} =""
> >>> RequestHeader set REMOTE_USER "anonymous"
> >>>
> >>> Hope this helps.
> >>>
> >>> 1.
> http://httpd.apache.org/docs/current/mod/directive-dict.html#Context
> >>> --
> >>> Shantanu.
> >>>
> >
> >
> > Leandro,
> >
> > I realized that above mentioned configuration is wrong. It will set
> RequestHeader to 'anonymous' regardless of authentication status. I think
> following config should work (still testing). In our case it resides outside
> of Location directive now. You may need to adjust it according to your
> setup:
> >
> > {{{
> ># Take the environment variable and set it as a header in the
> proxy request.
> >RewriteCond %{IS_SUBREQ} ^false$
> >RewriteCond %{LA-U:REMOTE_USER} (.+)
> >RewriteRule . - [E=RU:%1]
> ># Set RU to anonymous if No REMOTE_USER
> >RewriteCond %{IS_SUBREQ} ^false$
> >RewriteCond %{LA-U:REMOTE_USER} =""
> >RewriteRule . - [E=RU:"anonymous"]
> ># Set RequestHeader
> >RequestHead
Re: [galaxy-dev] public datasets/histories with external auth
Hi Shantanu,
Thank you for your update, I've done my config a little differently and it
appears to work just the same. The relevant part looks like this:
## ActiveDirectory authentication and authorization
AuthType Basic
AuthBasicProvider ldap
AuthName "R&D Galaxy Testing/QA Server"
AuthLDAPURL "ldap://my.server.com:389/OU=Users &
Workstations,DC=domain,DC=com?sAMAccountName?sub?(|(objectClass=person)(objectClass=group))"
# ...more AuthLDAP directives here...
RequestHeader set REMOTE_USER %{AUTHENTICATE_sAMAccountName}e
Order Allow,Deny
Allow from All
Satisfy Any
RequestHeader set REMOTE_USER "anonymous"
## Static content and reverse proxy
RewriteEngine On
RewriteRule ^/static/style/(.*)
/path/to/galaxy/galaxy_dist/static/june_2007_style/blue/$1 [L]
RewriteRule ^/static/scripts/(.*)
/path/to/galaxy/galaxy_dist/static/scripts/packed/$1 [L]
RewriteRule ^/static/(.*) /path/to/galaxy/galaxy_dist/static/$1 [L]
RewriteRule ^/favicon.ico /path/to/galaxy/galaxy_dist/static/favicon.ico
[L]
RewriteRule ^/robots.txt /path/to/galaxy/galaxy_dist/static/robots.txt
[L]
RewriteRule ^(.*) http://galaxy.server.hostname:8080 [P]
On Fri, Jul 1, 2011 at 12:13 AM, Shantanu Pavgi wrote:
>
> On Jun 30, 2011, at 6:34 AM, Leandro Hermida wrote:
>
>> Hi Nate and Shantanu,
>>
>> Thanks so much for the clear guidance, this works and sorry I didn't
>> read the Apache docs properly
>>
>> best,
>> Leandro
>>
>> On Thu, Jun 30, 2011 at 6:14 AM, Shantanu Pavgi wrote:
>>>
>>> On Jun 29, 2011, at 12:21 PM, Nate Coraor wrote:
>>>
>>> Leandro Hermida wrote:
>>>
>>> Hi Shantanu,
>>>
>>> In your Apache configuration exactly how did you set up an anonymous
>>>
>>> REMOTE_USER just for specific locations like the /datasets/ path? I'm
just
>>>
>>> looking at the Apache docs and the RequestHeader directive has a context
of
>>>
>>> the entire VirtualHost and cannot be put into a Location container so
I'm
>>>
>>> not sure how to do it.
>>>
>>> Hi Leandro,
>>>
>>> See the optional 'env=' argument and docs on the same for ways to make
>>> RequestHeader conditional:
>>>
>>>
http://httpd.apache.org/docs/current/mod/mod_headers.html#requestheader
>>>
>>> So, depending on the path accessed, you should be able to have
>>> mod_rewrite set an environment variable specifying which REMOTE_USER
>>> (real username or fake anonymouse user) should be set.
>>>
>>> You could also just set it as the anonymous user to start with and then
>>> use 'RequestHeader set' to overwrite it with the real username in the
>>> case that a real username is available.
>>>
>>> This is all just from glancing at the docs, though, I have not tried any
>>> of it out, and this sort of Apache trickery is always difficult to get
>>> right.
>>>
>>> --nate
>>>
>>>
>>>
>>> Leandro,
>>> The RequestHeader has a context of 'directory' as well, which includes
>>> , , , and containers [1]. So you
should
>>> be able to use it in Location directive.
>>> Following is a configuration snippet related to what Nate described in
his
>>> earlier response. We are setting REMOTE_USER variable to anonymous when
it's
>>> not set/empty.
>>>
>>> AuthType shibboleth
>>> ShibRequireSession off
>>> Require shibboleth
>>> RewriteCond %{LA-U:REMOTE_USER} =""
>>> RequestHeader set REMOTE_USER "anonymous"
>>>
>>> Hope this helps.
>>>
>>> 1. http://httpd.apache.org/docs/current/mod/directive-dict.html#Context
>>> --
>>> Shantanu.
>>>
>
>
> Leandro,
>
> I realized that above mentioned configuration is wrong. It will set
RequestHeader to 'anonymous' regardless of authentication status. I think
following config should work (still testing). In our case it resides outside
of Location directive now. You may need to adjust it according to your
setup:
>
> {{{
># Take the environment variable and set it as a header in the
proxy request.
>RewriteCond %{IS_SUBREQ} ^false$
>RewriteCond %{LA-U:REMOTE_USER} (.+)
>RewriteRule . - [E=RU:%1]
># Set RU to anonymous if No REMOTE_USER
>RewriteCond %{IS_SUBREQ} ^false$
>RewriteCond %{LA-U:REMOTE_USER} =""
>RewriteRule . - [E=RU:"anonymous"]
># Set RequestHeader
>RequestHeader set REMOTE_USER %{RU}e
> }}}
>
>
> --
> Shantanu.
>
>
___
Please keep all replies on the list by using "reply all"
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
http://lists.bx.psu.edu/
Re: [galaxy-dev] public datasets/histories with external auth
On Jun 30, 2011, at 6:34 AM, Leandro Hermida wrote:
> Hi Nate and Shantanu,
>
> Thanks so much for the clear guidance, this works and sorry I didn't
> read the Apache docs properly
>
> best,
> Leandro
>
> On Thu, Jun 30, 2011 at 6:14 AM, Shantanu Pavgi wrote:
>>
>> On Jun 29, 2011, at 12:21 PM, Nate Coraor wrote:
>>
>> Leandro Hermida wrote:
>>
>> Hi Shantanu,
>>
>> In your Apache configuration exactly how did you set up an anonymous
>>
>> REMOTE_USER just for specific locations like the /datasets/ path? I'm just
>>
>> looking at the Apache docs and the RequestHeader directive has a context of
>>
>> the entire VirtualHost and cannot be put into a Location container so I'm
>>
>> not sure how to do it.
>>
>> Hi Leandro,
>>
>> See the optional 'env=' argument and docs on the same for ways to make
>> RequestHeader conditional:
>>
>>http://httpd.apache.org/docs/current/mod/mod_headers.html#requestheader
>>
>> So, depending on the path accessed, you should be able to have
>> mod_rewrite set an environment variable specifying which REMOTE_USER
>> (real username or fake anonymouse user) should be set.
>>
>> You could also just set it as the anonymous user to start with and then
>> use 'RequestHeader set' to overwrite it with the real username in the
>> case that a real username is available.
>>
>> This is all just from glancing at the docs, though, I have not tried any
>> of it out, and this sort of Apache trickery is always difficult to get
>> right.
>>
>> --nate
>>
>>
>>
>> Leandro,
>> The RequestHeader has a context of 'directory' as well, which includes
>> , , , and containers [1]. So you should
>> be able to use it in Location directive.
>> Following is a configuration snippet related to what Nate described in his
>> earlier response. We are setting REMOTE_USER variable to anonymous when it's
>> not set/empty.
>>
>> AuthType shibboleth
>> ShibRequireSession off
>> Require shibboleth
>> RewriteCond %{LA-U:REMOTE_USER} =""
>> RequestHeader set REMOTE_USER "anonymous"
>>
>> Hope this helps.
>>
>> 1. http://httpd.apache.org/docs/current/mod/directive-dict.html#Context
>> --
>> Shantanu.
>>
Leandro,
I realized that above mentioned configuration is wrong. It will set
RequestHeader to 'anonymous' regardless of authentication status. I think
following config should work (still testing). In our case it resides outside of
Location directive now. You may need to adjust it according to your setup:
{{{
# Take the environment variable and set it as a header in the proxy
request.
RewriteCond %{IS_SUBREQ} ^false$
RewriteCond %{LA-U:REMOTE_USER} (.+)
RewriteRule . - [E=RU:%1]
# Set RU to anonymous if No REMOTE_USER
RewriteCond %{IS_SUBREQ} ^false$
RewriteCond %{LA-U:REMOTE_USER} =""
RewriteRule . - [E=RU:"anonymous"]
# Set RequestHeader
RequestHeader set REMOTE_USER %{RU}e
}}}
--
Shantanu.
___
Please keep all replies on the list by using "reply all"
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
http://lists.bx.psu.edu/
Re: [galaxy-dev] public datasets/histories with external auth
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//h/ >> - /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&operation=View&id=24d84bcf64116fe7 >> >> 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?redirect_url=http%3A%2F%2Fgenome.ucsc.edu%2Fcgi-bin%2FhgTracks%3Fdb%3Dmm9%26position%3Dchr1%3A20048750-20608024%26hgt.customText%3D%25s&display_url=http%3A%2F%2Fgalaxy.uabgrid.uab.edu%2Froot%2Fdisplay_as%3Fid%3D3423%26display_app%3Ducsc%26authz_method%3Ddisplay_at >> >> 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'. >> >> Now we are opening up certain URL patterns to be accessed as >> 'anonymous@mail.domain' user. These URL >> patterns include following formats as mentioned - /datasets, /history, >> /u//h, 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. >> ___ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
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//h/ > - /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&operation=View&id=24d84bcf64116fe7 > > 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?redirect_url=http%3A%2F%2Fgenome.ucsc.edu%2Fcgi-bin%2FhgTracks%3Fdb%3Dmm9%26position%3Dchr1%3A20048750-20608024%26hgt.customText%3D%25s&display_url=http%3A%2F%2Fgalaxy.uabgrid.uab.edu%2Froot%2Fdisplay_as%3Fid%3D3423%26display_app%3Ducsc%26authz_method%3Ddisplay_at > > 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'. > > Now we are opening up certain URL patterns to be accessed as > 'anonymous@mail.domain' user. These URL > patterns include following formats as mentioned - /datasets, /history, > /u//h, 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. > ___ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
Re: [galaxy-dev] public datasets/histories with external auth
Hi Nate and Shantanu,
Thanks so much for the clear guidance, this works and sorry I didn't
read the Apache docs properly
best,
Leandro
On Thu, Jun 30, 2011 at 6:14 AM, Shantanu Pavgi wrote:
>
> On Jun 29, 2011, at 12:21 PM, Nate Coraor wrote:
>
> Leandro Hermida wrote:
>
> Hi Shantanu,
>
> In your Apache configuration exactly how did you set up an anonymous
>
> REMOTE_USER just for specific locations like the /datasets/ path? I'm just
>
> looking at the Apache docs and the RequestHeader directive has a context of
>
> the entire VirtualHost and cannot be put into a Location container so I'm
>
> not sure how to do it.
>
> Hi Leandro,
>
> See the optional 'env=' argument and docs on the same for ways to make
> RequestHeader conditional:
>
> http://httpd.apache.org/docs/current/mod/mod_headers.html#requestheader
>
> So, depending on the path accessed, you should be able to have
> mod_rewrite set an environment variable specifying which REMOTE_USER
> (real username or fake anonymouse user) should be set.
>
> You could also just set it as the anonymous user to start with and then
> use 'RequestHeader set' to overwrite it with the real username in the
> case that a real username is available.
>
> This is all just from glancing at the docs, though, I have not tried any
> of it out, and this sort of Apache trickery is always difficult to get
> right.
>
> --nate
>
>
>
> Leandro,
> The RequestHeader has a context of 'directory' as well, which includes
> , , , and containers [1]. So you should
> be able to use it in Location directive.
> Following is a configuration snippet related to what Nate described in his
> earlier response. We are setting REMOTE_USER variable to anonymous when it's
> not set/empty.
>
> AuthType shibboleth
> ShibRequireSession off
> Require shibboleth
> RewriteCond %{LA-U:REMOTE_USER} =""
> RequestHeader set REMOTE_USER "anonymous"
>
> Hope this helps.
>
> 1. http://httpd.apache.org/docs/current/mod/directive-dict.html#Context
> --
> Shantanu.
>
___
Please keep all replies on the list by using "reply all"
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
http://lists.bx.psu.edu/
Re: [galaxy-dev] public datasets/histories with external auth
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//h/ - /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&operation=View&id=24d84bcf64116fe7 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?redirect_url=http%3A%2F%2Fgenome.ucsc.edu%2Fcgi-bin%2FhgTracks%3Fdb%3Dmm9%26position%3Dchr1%3A20048750-20608024%26hgt.customText%3D%25s&display_url=http%3A%2F%2Fgalaxy.uabgrid.uab.edu%2Froot%2Fdisplay_as%3Fid%3D3423%26display_app%3Ducsc%26authz_method%3Ddisplay_at 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? 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'. Now we are opening up certain URL patterns to be accessed as 'anonymous@mail.domain' user. These URL patterns include following formats as mentioned - /datasets, /history, /u//h, 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. ___ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
Re: [galaxy-dev] public datasets/histories with external auth
On Jun 29, 2011, at 12:21 PM, Nate Coraor wrote:
Leandro Hermida wrote:
Hi Shantanu,
In your Apache configuration exactly how did you set up an anonymous
REMOTE_USER just for specific locations like the /datasets/ path? I'm just
looking at the Apache docs and the RequestHeader directive has a context of
the entire VirtualHost and cannot be put into a Location container so I'm
not sure how to do it.
Hi Leandro,
See the optional 'env=' argument and docs on the same for ways to make
RequestHeader conditional:
http://httpd.apache.org/docs/current/mod/mod_headers.html#requestheader
So, depending on the path accessed, you should be able to have
mod_rewrite set an environment variable specifying which REMOTE_USER
(real username or fake anonymouse user) should be set.
You could also just set it as the anonymous user to start with and then
use 'RequestHeader set' to overwrite it with the real username in the
case that a real username is available.
This is all just from glancing at the docs, though, I have not tried any
of it out, and this sort of Apache trickery is always difficult to get
right.
--nate
Leandro,
The RequestHeader has a context of 'directory' as well, which includes
, , , and containers [1]. So you should be
able to use it in Location directive.
Following is a configuration snippet related to what Nate described in his
earlier response. We are setting REMOTE_USER variable to anonymous when it's
not set/empty.
AuthType shibboleth
ShibRequireSession off
Require shibboleth
RewriteCond %{LA-U:REMOTE_USER} =""
RequestHeader set REMOTE_USER "anonymous"
Hope this helps.
1. http://httpd.apache.org/docs/current/mod/directive-dict.html#Context
--
Shantanu.
___
Please keep all replies on the list by using "reply all"
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
http://lists.bx.psu.edu/
Re: [galaxy-dev] public datasets/histories with external auth
Leandro Hermida wrote:
> Hi Shantanu,
>
> In your Apache configuration exactly how did you set up an anonymous
> REMOTE_USER just for specific locations like the /datasets/ path? I'm just
> looking at the Apache docs and the RequestHeader directive has a context of
> the entire VirtualHost and cannot be put into a Location container so I'm
> not sure how to do it.
Hi Leandro,
See the optional 'env=' argument and docs on the same for ways to make
RequestHeader conditional:
http://httpd.apache.org/docs/current/mod/mod_headers.html#requestheader
So, depending on the path accessed, you should be able to have
mod_rewrite set an environment variable specifying which REMOTE_USER
(real username or fake anonymouse user) should be set.
You could also just set it as the anonymous user to start with and then
use 'RequestHeader set' to overwrite it with the real username in the
case that a real username is available.
This is all just from glancing at the docs, though, I have not tried any
of it out, and this sort of Apache trickery is always difficult to get
right.
--nate
>
> thanks,
> Leandro
>
> On Wed, Jun 22, 2011 at 9:40 PM, Shantanu Pavgi wrote:
>
> >
> > On Jun 20, 2011, at 4:10 PM, Shantanu Pavgi wrote:
> >
> > >
> > > On Jun 20, 2011, at 2:40 PM, Nate Coraor wrote:
> > >
> > >> Shantanu Pavgi wrote:
> > >>> Hi,
> > >>>
> > >>> We have a galaxy server setup using external shibboleth authentication.
> > While we would like to have site behind authentication realm, there are
> > instances when our galaxy datasets/histories need to be accessible publicly
> > from other websites. We tried adding an exception to auth rule for /datasets
> > path using Location directive in apache web server configuration, however
> > galaxy server returned an error as:
> > >>>
> > >>> {{{
> > >>> Access to Galaxy is denied
> > >>> Galaxy is configured to authenticate users via an external method (such
> > as HTTP authentication in Apache), but a username was not provided by the
> > upstream (proxy) server. This is generally due to a misconfiguration in the
> > upstream server.
> > >>> }}}
> > >>>
> > >>> Is there any way to share public histories and datasets when galaxy is
> > using external authentication mechanism? I have thought about setting up
> > (fake) anonymous REMOTE_USER variable for /datasets path, but not sure
> > whether this is correct approach. Also, would it require any galaxy code
> > changes? Any thoughts?
> > >>
> > >> Hi Shantanu,
> > >>
> > >> That's about all you can do, or modify
> > >> lib/galaxy/web/framework/middleware/remoteuser.py to let these
> > >> connections through. I would suggest the former solution of setting a
> > >> header in Apache, but only set it if the user is not authenticated.
> > >>
> > >> --nate
> > >
> > >
> > > Thanks for the reply Nate. That's helpful.
> > >
> > > --
> > > Shantanu.
> > >
> >
> >
> > I did a test by excluding following URLs from Apache-Shibboleth external
> > authentication and it seems to be working:
> > - /datasets/
> > - /u//h/
> > - /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?
> >
> > 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.
> >
> >
> > Thanks,
> > Shantanu.
> >
> >
> >
> >
> > ___
> > Please keep all replies on the list by using "reply all"
> > in your mail client. To manage your subscriptions to this
> > and other Galaxy lists, please use the interface at:
> >
> > http://lists.bx.psu.edu/
> >
___
Please keep all replies on the list by using "reply all"
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
http://lists.bx.psu.edu/
Re: [galaxy-dev] public datasets/histories with external auth
Hi Shantanu,
In your Apache configuration exactly how did you set up an anonymous
REMOTE_USER just for specific locations like the /datasets/ path? I'm just
looking at the Apache docs and the RequestHeader directive has a context of
the entire VirtualHost and cannot be put into a Location container so I'm
not sure how to do it.
thanks,
Leandro
On Wed, Jun 22, 2011 at 9:40 PM, Shantanu Pavgi wrote:
>
> On Jun 20, 2011, at 4:10 PM, Shantanu Pavgi wrote:
>
> >
> > On Jun 20, 2011, at 2:40 PM, Nate Coraor wrote:
> >
> >> Shantanu Pavgi wrote:
> >>> Hi,
> >>>
> >>> We have a galaxy server setup using external shibboleth authentication.
> While we would like to have site behind authentication realm, there are
> instances when our galaxy datasets/histories need to be accessible publicly
> from other websites. We tried adding an exception to auth rule for /datasets
> path using Location directive in apache web server configuration, however
> galaxy server returned an error as:
> >>>
> >>> {{{
> >>> Access to Galaxy is denied
> >>> Galaxy is configured to authenticate users via an external method (such
> as HTTP authentication in Apache), but a username was not provided by the
> upstream (proxy) server. This is generally due to a misconfiguration in the
> upstream server.
> >>> }}}
> >>>
> >>> Is there any way to share public histories and datasets when galaxy is
> using external authentication mechanism? I have thought about setting up
> (fake) anonymous REMOTE_USER variable for /datasets path, but not sure
> whether this is correct approach. Also, would it require any galaxy code
> changes? Any thoughts?
> >>
> >> Hi Shantanu,
> >>
> >> That's about all you can do, or modify
> >> lib/galaxy/web/framework/middleware/remoteuser.py to let these
> >> connections through. I would suggest the former solution of setting a
> >> header in Apache, but only set it if the user is not authenticated.
> >>
> >> --nate
> >
> >
> > Thanks for the reply Nate. That's helpful.
> >
> > --
> > Shantanu.
> >
>
>
> I did a test by excluding following URLs from Apache-Shibboleth external
> authentication and it seems to be working:
> - /datasets/
> - /u//h/
> - /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?
>
> 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.
>
>
> Thanks,
> Shantanu.
>
>
>
>
> ___
> Please keep all replies on the list by using "reply all"
> in your mail client. To manage your subscriptions to this
> and other Galaxy lists, please use the interface at:
>
> http://lists.bx.psu.edu/
>
___
Please keep all replies on the list by using "reply all"
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
http://lists.bx.psu.edu/
Re: [galaxy-dev] public datasets/histories with external auth
Shantanu Pavgi wrote: > > I did a test by excluding following URLs from Apache-Shibboleth external > authentication and it seems to be working: > - /datasets/ > - /u//h/ > - /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." > 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. --nate > > > Thanks, > Shantanu. > > > > ___ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
Re: [galaxy-dev] public datasets/histories with external auth
On Jun 20, 2011, at 4:10 PM, Shantanu Pavgi wrote:
>
> On Jun 20, 2011, at 2:40 PM, Nate Coraor wrote:
>
>> Shantanu Pavgi wrote:
>>> Hi,
>>>
>>> We have a galaxy server setup using external shibboleth authentication.
>>> While we would like to have site behind authentication realm, there are
>>> instances when our galaxy datasets/histories need to be accessible publicly
>>> from other websites. We tried adding an exception to auth rule for
>>> /datasets path using Location directive in apache web server
>>> configuration, however galaxy server returned an error as:
>>>
>>> {{{
>>> Access to Galaxy is denied
>>> Galaxy is configured to authenticate users via an external method (such as
>>> HTTP authentication in Apache), but a username was not provided by the
>>> upstream (proxy) server. This is generally due to a misconfiguration in the
>>> upstream server.
>>> }}}
>>>
>>> Is there any way to share public histories and datasets when galaxy is
>>> using external authentication mechanism? I have thought about setting up
>>> (fake) anonymous REMOTE_USER variable for /datasets path, but not sure
>>> whether this is correct approach. Also, would it require any galaxy code
>>> changes? Any thoughts?
>>
>> Hi Shantanu,
>>
>> That's about all you can do, or modify
>> lib/galaxy/web/framework/middleware/remoteuser.py to let these
>> connections through. I would suggest the former solution of setting a
>> header in Apache, but only set it if the user is not authenticated.
>>
>> --nate
>
>
> Thanks for the reply Nate. That's helpful.
>
> --
> Shantanu.
>
I did a test by excluding following URLs from Apache-Shibboleth external
authentication and it seems to be working:
- /datasets/
- /u//h/
- /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?
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.
Thanks,
Shantanu.
___
Please keep all replies on the list by using "reply all"
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
http://lists.bx.psu.edu/
Re: [galaxy-dev] public datasets/histories with external auth
On Jun 20, 2011, at 2:40 PM, Nate Coraor wrote:
> Shantanu Pavgi wrote:
>> Hi,
>>
>> We have a galaxy server setup using external shibboleth authentication.
>> While we would like to have site behind authentication realm, there are
>> instances when our galaxy datasets/histories need to be accessible publicly
>> from other websites. We tried adding an exception to auth rule for /datasets
>> path using Location directive in apache web server configuration, however
>> galaxy server returned an error as:
>>
>> {{{
>> Access to Galaxy is denied
>> Galaxy is configured to authenticate users via an external method (such as
>> HTTP authentication in Apache), but a username was not provided by the
>> upstream (proxy) server. This is generally due to a misconfiguration in the
>> upstream server.
>> }}}
>>
>> Is there any way to share public histories and datasets when galaxy is using
>> external authentication mechanism? I have thought about setting up (fake)
>> anonymous REMOTE_USER variable for /datasets path, but not sure whether
>> this is correct approach. Also, would it require any galaxy code changes?
>> Any thoughts?
>
> Hi Shantanu,
>
> That's about all you can do, or modify
> lib/galaxy/web/framework/middleware/remoteuser.py to let these
> connections through. I would suggest the former solution of setting a
> header in Apache, but only set it if the user is not authenticated.
>
> --nate
Thanks for the reply Nate. That's helpful.
--
Shantanu.
___
Please keep all replies on the list by using "reply all"
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
http://lists.bx.psu.edu/
Re: [galaxy-dev] public datasets/histories with external auth
Shantanu Pavgi wrote:
> Hi,
>
> We have a galaxy server setup using external shibboleth authentication. While
> we would like to have site behind authentication realm, there are instances
> when our galaxy datasets/histories need to be accessible publicly from other
> websites. We tried adding an exception to auth rule for /datasets path using
> Location directive in apache web server configuration, however galaxy server
> returned an error as:
>
> {{{
> Access to Galaxy is denied
> Galaxy is configured to authenticate users via an external method (such as
> HTTP authentication in Apache), but a username was not provided by the
> upstream (proxy) server. This is generally due to a misconfiguration in the
> upstream server.
> }}}
>
> Is there any way to share public histories and datasets when galaxy is using
> external authentication mechanism? I have thought about setting up (fake)
> anonymous REMOTE_USER variable for /datasets path, but not sure whether this
> is correct approach. Also, would it require any galaxy code changes? Any
> thoughts?
Hi Shantanu,
That's about all you can do, or modify
lib/galaxy/web/framework/middleware/remoteuser.py to let these
connections through. I would suggest the former solution of setting a
header in Apache, but only set it if the user is not authenticated.
--nate
>
> Thanks,
> Shantanu.
> ___
> Please keep all replies on the list by using "reply all"
> in your mail client. To manage your subscriptions to this
> and other Galaxy lists, please use the interface at:
>
> http://lists.bx.psu.edu/
___
Please keep all replies on the list by using "reply all"
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
http://lists.bx.psu.edu/
[galaxy-dev] public datasets/histories with external auth
Hi,
We have a galaxy server setup using external shibboleth authentication. While
we would like to have site behind authentication realm, there are instances
when our galaxy datasets/histories need to be accessible publicly from other
websites. We tried adding an exception to auth rule for /datasets path using
Location directive in apache web server configuration, however galaxy server
returned an error as:
{{{
Access to Galaxy is denied
Galaxy is configured to authenticate users via an external method (such as HTTP
authentication in Apache), but a username was not provided by the upstream
(proxy) server. This is generally due to a misconfiguration in the upstream
server.
}}}
Is there any way to share public histories and datasets when galaxy is using
external authentication mechanism? I have thought about setting up (fake)
anonymous REMOTE_USER variable for /datasets path, but not sure whether this
is correct approach. Also, would it require any galaxy code changes? Any
thoughts?
Thanks,
Shantanu.
___
Please keep all replies on the list by using "reply all"
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
http://lists.bx.psu.edu/
