Username and Password authentication

[vallerul]

May I know if it is possible to get username and password authentication part of the URL access, so that we can prevent other users on the same system to access the URL on the same network/server?

The idea is that we should be able to set username and password in a configuration file, and we are asked for the same as part of HTTP headers , when accessing the URL.

[jose-d]

this would be really helpful for our site as well. matlab-proxy, combined with tools like osc ondemand would bring completely new level of experience to our users. Any form of authentication (user/pass, certificate, etc.) would be helpful.

[prabhakk-mw]

@vallerul , @jose-d
Thank you for reporting this enhancement request. We are actively working to introduce this capability.

In your environments, is it safe to assume that your users will have access to the machine on which their matlab-proxy server will be running? This would help me design a solution which allows users to recover their access tokens once they have closed their browser tabs or when they attempt to use the URL from a new browser.

[jose-d]

@prabhakk-mw my environment (HPC system) consists from many compute nodes where jobs are scheduled by SLURM [1] job manager. Users ( mostly brain imaging scientists ) request resources (CPU cores at compute machines) using slurm batch[2] scripts in terminal, or using web interface OpenOnDemand [3] - which brews and submit the sbatch script automatically for them, and does all the needed piping, port-forwarding/proxying for interactive apps, etc.

In my two particular HPC sites I manage, allocated resources ( compute machines ) are accessible to users using ssh when they have active job. But from what I know, this is not always the case from security/architecture/other reasons at other sites.

Because of this eventuality, one possible scenario IMO would be to push the secret at the time of job creation / start of the instance. Such secret could be kept by the submitting entity (live person, scripting/web-GUI around batch system), and could be reused for case of closing the websession.

I have no strong opinion if the secret should be passed to matlab-proxy via environment variables of via secrets file.

To auth to the running instance - HTTP GET would be nice, something like https://node5123.hpc.local:8081/matlab-proxy?token=SecretTokenValidForInstanceRuntime ?

@johrstrom agrees?

[1] https://slurm.schedmd.com/documentation.html
[2] https://slurm.schedmd.com/sbatch.html
[3] https://openondemand.org/

[johrstrom]

@johrstrom agrees?

I think passing secrets as query prameters is fine. I think lots of folks do this. In case anyone's interested I setup a scheme with unshare'd network namepsace for tensorboard, another app that doens't have authentication. Of course it requires subuid's enabled at your site.

https://github.com/OSC/bc_osc_tensorboard/tree/gtc

[vallerul]

@prabhakk-mw<https://github.com/prabhakk-mw> My environment is like the one that @jose-d<https://github.com/jose-d> mentioned , except that we use LSF scheduler instead of Slurm. So, passing secrets as query parameters is fine for me too. For example - Something like how Jupyter notebooks work would be great. Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: Jeff Ohrstrom ***@***.***> Sent: Friday, April 29, 2022 8:34:39 AM To: mathworks/matlab-proxy ***@***.***> Cc: Valleru, Lohit/Technology Division ***@***.***>; Mention ***@***.***> Subject: [EXTERNAL] Re: [mathworks/matlab-proxy] Username and Password authentication (Issue #2) @johrstrom<https://github.com/johrstrom> agrees? I think passing secrets as query prameters is fine. I think lots of folks do this. In case anyone's interested I setup a scheme with unshare'd network namepsace for tensorboard, another app that doens't have authentication. Of course it requires subuid's enabled at your site. https://github.com/OSC/bc_osc_tensorboard/tree/gtc — Reply to this email directly, view it on GitHub<#2 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AXLSF6VEWQ2CUHR6CRIMB73VHPQO7ANCNFSM5UPLZKJA>. You are receiving this because you were mentioned.Message ID: ***@***.***> *** Only open attachments or links from trusted senders. Report phishing to ***@***.*** *** ===================================================================== Please note that this e-mail and any files transmitted from Memorial Sloan Kettering Cancer Center may be privileged, confidential, and protected from disclosure under applicable law. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this communication or any of its attachments is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to this message and deleting this message, any attachments, and all copies and backups from your computer.

[prabhakk-mw]

@vallerul @jose-d Please let us know if the newly introduced Token Authentication support in v0.3.0 satisfies your use cases. Thank you.