Thanks Eric,
I'm sure this will be useful to many Galaxy admins!

I've edited a bit the wiki page, in particular I've updated the code to use roles instead of groups, which is more appropriate in the context of access control.


Il 2013-12-07 03:07 Rasche Eric ha scritto:
Hi Nicola,
Just thought I'd write back since I added a Wiki page in Admin/Config
[11] area for implementing access control.
Thank you for sharing the snippets you posted in the email thread you
linked me! [12]
Eric Rasche
06.11.2013, 18:57, "Eric Rasche" <>:

Hi Nicola,

Oh, excellent. I must've skipped over that, given the strange title
the thread.

Your solution at the end of that thread is very promising, and
handles failure MUCH better than mine does (i.e. raising exceptions
not breaking a workflow if the user isn't permitted access.)

(Did you put it on the galaxy wiki anywhere? If it weren't for you
linking that, I never would've known about it and that's very useful

In my organisation's case; if a user isn't allowed access to a given
tool, we believe that

- - galaxy has no reason to admit it exists
- - galaxy should not share default information about a tool

Which is a bit different from the case of having a license to use a
tool. For licensing issues, naturally it would be fine to say "yes
exists and if you can't run it, obtain a license".

For my org's case, we might want to store administrative tools (for
other services) in galaxy. It's a very convenient platform for more
just bioinformatics and we have some non-technical people on staff
occasionally need to pull various data sets from various
database backups/etc. Students and clients who use our galaxy
don't need to know that these tools are available.


On 11/06/2013 12:12 PM, Nicola Soranzo wrote:

 Hi Eric,
 please also take a look at this mailing list thread:

 If you are interested in the is_user_in_group solution, I have a
 slightly updated version which also uses roles instead of


 Il giorno mer, 06/11/2013 alle 11.38 -0600, Eric Rasche ha

 Howdy devs,

 I've implemented some rather basic tool access control and am
 for feedback on my implementation.

 # Why

 Our organisation wanted the ability to restrict tools to
 users/roles. As such I've implemented as an "execute" tag
which can be
 applied to either <section> or <tools> in the tool
configuration file.

 # Example galaxy-admin changes

 For example:

   <section execute=" [1], [2]" id="EncodeTools"
name="ENCODE Tools">
     <tool file="encode/gencode_partition.xml" />
     <tool execute=" [3]"
file="encode/random_intervals.xml" />

 which would allow A and B to access gencode_parition, but only
B would
 be able to access random_intervals. To put it explicity

 - by default, everyone can access all tools
 - if section level permissions are set, then those are set as
 for all tools in that section
 - if tool permissions are set, they will override the

 # Pros and Cons

 There are some good features

 - non-accessible tools won't show up in the left hand panel,
based on user
 - non-accessible tools cannot be run or accessed.

 There are some caveats however.

 - existence of tools is not completely hidden.
 - Labels are not hidden at all.
 - workflows break completely if a tool is unavailable to a
shared user
 and the user copies+edits. They can be copied, and viewed
(says tool not
 found), but cannot be edited.

 Tool names/id/version info can be found in the javascript
object due to
 the call to app.toolbox.tool_panel.items() in
 templates/webapps/galaxy/workflow/editor.mako, as that returns
the raw
 tool list, rather than one that's filtered on whether or not
the user
 has access. I'm yet to figure out a clean fix for this.
 empty sections are still shown even if there aren't tools
listed in them.

 For a brief overview of my changes, please see the attached
diff. (It's
 missing one change because I wasn't being careful and started
work on
 multiple different features)

 # Changeset overview

 In brief, most of the changes consist of
 - new method in model.User to check if an array of roles
overlaps at all
 with a user's roles
 - modifications to appropriate files for reading in the new
 tool_config.xml's options
 - modification to get_tool to pass user information, as
whether or not a
 tool exists is now dependent on who is asking.

 Please let me know if you have input on this before I create a
 request on this feature.

 # Fixes

 I believe this will fix a number of previously brought up
issues (at
 least to my understanding of the issues listed)

 + (I saw some solution where they were adding "_beta" to tool
 which gave permissions to developers somewhere, but cannot
find that now)

 Eric Rasche

 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: [5]

 To search Galaxy mailing lists use the unified search at: [6]

- --
Eric Rasche
Programmer II
Center for Phage Technology
Texas A&M University
College Station, TX 77843
404-692-2048 [9] [10]

Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -


Eric Rasche
Programmer II
Center for Phage Technology
Texas A&M University
College Station, TX 77843
404-692-2048 [13] [14]


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:

To search Galaxy mailing lists use the unified search at:

Reply via email to