Re: [galaxy-dev] Password Parameter Opinions

[Eric Rasche]

Hi Katherine,

Not controversial at all ;) different sub-groups of the galaxy community
just have different needs. I'm in one of those that needs this, but I
likewise agree with the devs that a "password" field is not an optimal
solution.

I've proposed something a while back which might achieve what you need,
but it is a long ways (~1-2 months on my current calendar) from
implementation which I realise isn't very helpful right now. (If there
are people who are motivated for this idea, I would be happy to work
with them on this. I'm more interested in the functionality than I am in
any credit for implementing it ;) )

I'm proposing a framework for "Credentials for Remote Services" as this
is a pretty generic problem. The gist of it is:

  * There are tools which need user provided credentials for talking to
remote services.
  * The tool should be able to register that it would like all
credentials under a certain namespace (e.g. a tool in my apollo
suite would want all credentials under the "apollo" path). E.g. in a
tool:
  o The command block uses something like "my_script.sh
$apollo_password"
  o The inputs contains something like ''
  o And perhaps somewhere else in the tool we have
'
  o Galaxy, upon seeing the credentials block, would expose a user
configuration setting, allowing the user to register as many
services as they want with this form for entering credentials.
  o The tool, upon looking through the user's configured credentials
in Galaxy, would allow the user to select which credentials they
wish to use.

I am not tackling the encryption portion too heavily, credentials would
be encrypted with the galaxy id_secret going into the database (and
probably salted as well), and then exposed as environment variables orso
when the job is constructed. Anything past that is increasingly less
important for me, any sys admin running Galaxy has access to do much
more malicious things anyway.

There are a couple of specifics I still need to work out (mostly syntax
things for how tools should declare these variables, and how they should
consume them) but I think this would be a much more generic option and
allow for more exciting things in the future. This is what I envision
people selecting in the UI.


Regards,
Eric

On 28. juli 2016 10:53, Katherine Beaulieu wrote:
> Hi Everyone,
> I know this is sort of a controversial topic so I will try to tread
> lightly. It seems that for a couple of years the idea of a password
> parameter for Galaxy tools has come up a lot but has also been
> rejected a lot although I believe there is a lot of merit to it. I
> have found at least two other times where people have tried to
> implement this and it was rejected, but there must have been a reason
> why they needed that parameter. My situation currently is that I have
> created two tools in Galaxy which communicate with another software
> called iRODS which needs authentication from the user. In my own
> department, there is another tool that was created which needed
> authentication from the user but the developer had to create some
> other workaround for this problem. 
>
> In terms of the work I have done for this so far, I have been working
> off the latest release version of Galaxy. I have implemented the field
> so that it is obfuscated in the tool form view as well as on the tool
> info page. I will next be looking into storing the parameter in an
> environment variable so it doesn't get passed through the command line
> and encrypting the password before it enters the database. Speaking
> with a co-worker of mine, we discussed the possibility of implementing
> two option, irreversible encryption of the password as it gets entered
> into the database but then making the tool not workflow compatible, or
> using regular encryption and making the tool workflow compatible. I
> look forward to hearing your opinions and ideas.
>
> Katherine
>
>
> ___
> 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:
>   https://lists.galaxyproject.org/
>
> To search Galaxy mailing lists use the unified search at:
>   http://galaxyproject.org/search/mailinglists/

-- 
Eric Rasche
Programmer II

Center for Phage Technology
Rm 312A, Biochemistry & Biophysics
Texas A University
College Station, TX 77843
e...@tamu.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:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

Re: [galaxy-dev] Password Parameter Opinions

[Mohamed Kassam]

Hello Katherine,
You will save a lot the work some people are doing now.

You are not alone to face the same problem. We discussed last time about
that, iRODS, etc...

I think it is a good idea to emcrypt the password  before it enters the
database. That Galaxy don't keep any trace of user name or password on the
system.
I don't know how much it is difficult for that. I tried to modify the
databsae but I had some issues. So I updated this morning the new version
of Galaxy. I will check if I can manage.
Let know us what change you made by putting on the github.

Thanks in advance,

Mohamed

2016-07-28 12:53 GMT+02:00 Katherine Beaulieu <
katherine.beaulieu...@gmail.com>:

> Hi Everyone,
> I know this is sort of a controversial topic so I will try to tread
> lightly. It seems that for a couple of years the idea of a password
> parameter for Galaxy tools has come up a lot but has also been rejected a
> lot although I believe there is a lot of merit to it. I have found at least
> two other times where people have tried to implement this and it was
> rejected, but there must have been a reason why they needed that parameter.
> My situation currently is that I have created two tools in Galaxy which
> communicate with another software called iRODS which needs authentication
> from the user. In my own department, there is another tool that was created
> which needed authentication from the user but the developer had to create
> some other workaround for this problem.
>
> In terms of the work I have done for this so far, I have been working off
> the latest release version of Galaxy. I have implemented the field so that
> it is obfuscated in the tool form view as well as on the tool info page. I
> will next be looking into storing the parameter in an environment variable
> so it doesn't get passed through the command line and encrypting the
> password before it enters the database. Speaking with a co-worker of mine,
> we discussed the possibility of implementing two option, irreversible
> encryption of the password as it gets entered into the database but then
> making the tool not workflow compatible, or using regular encryption and
> making the tool workflow compatible. I look forward to hearing your
> opinions and ideas.
>
> Katherine
>
> ___
> 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:
>   https://lists.galaxyproject.org/
>
> To search Galaxy mailing lists use the unified search at:
>   http://galaxyproject.org/search/mailinglists/
>
___
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:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/