Credentials and token

[ferrigno]

In my notebooks, I need to specify a token to upload to the gallery or access private data. Currently, it is a parameter.
By trying another service (nb2w-example), I received the following message

Dear User,
you receive this message because at 2024-02-08 18:39:17 ( 42.1 seconds ago ) you submitted a request
for a image from the service provided by University of Geneva
available at the URL https://staging.odahub.fr/mmoda/.

which contains a token with my credentials on the staging instance.

I have two main questions:

• How can i access the token from my notebooks so to pass it to the MMODA service? (the notebooks do not do it explicitly)
• Could the credentials be synchronized or at least the roles be common among the different instances of MMODA ?

[volodymyrss]

In my notebooks, I need to specify a token to upload to the gallery or access private data. Currently, it is a parameter. By trying another service (nb2w-example), I received the following message

Dear User,
you receive this message because at 2024-02-08 18:39:17 ( 42.1 seconds ago ) you submitted a request
for a image from the service provided by University of Geneva
available at the URL https://staging.odahub.fr/mmoda/.

which contains a token with my credentials on the staging instance.

I have two main questions:

* How can i access the token from my notebooks so to pass it to the MMODA service? (the notebooks do not do it explicitly)

For now, is there any issue with passing it as an extra parameter?

The token will be eventually injected according to oda-hub/nb2workflow#138
MMODA is just one of the resources for which we need keep track of credentials and provide them to the workflow.

* Could the credentials be synchronized or at least the roles be common among the different instances of MMODA ?

For staging, instance, there is no point to synchronize credentials, it's meant to be used for tests.

When we move on to have multiple production instances (or decide to consider staging instance one of the production instances) we can adapt different auth infrastructure (it's partially adapted in MMODA already) which will grant authorizations accordingly.

This issue is details on one of the use cases described in oda-hub/nb2workflow#138. I will move it.

[ferrigno]

No issues in passing it as extra parameter

[ferrigno]

If you need to test consistency of credentials, some form of synchronization of credentials is advisable.

[volodymyrss]

If you need to test consistency of credentials, some form of synchronization of credentials is advisable.

Not sure what you mean here by synchronization. If you mean copying - that's a very bad idea.

[ferrigno]

what I mean is that I can have the same roles in different instances and that the token from staging frontend can be used as the token from production frontend to submit jobs to the dispatcher in Geneva using oda_api For testing, it would be maybe enough to have the same roles and these can be updated "by hand" by the user without bothering the administrator (the user is supposed to be a tester in the staging instance).

[volodymyrss]

what I mean is that I can have the same roles in different instances and that the token from staging frontend can be used as the token from production frontend to submit jobs to the dispatcher in Geneva using oda_api For testing, it would be maybe enough to have the same roles and these can be updated "by hand" by the user without bothering the administrator (the user is supposed to be a tester in the staging instance).

I understand what you are trying to achieve, but the outline if the implementation you are suggesting is incomplete and unfeasible.
The feature which enables what you need in a feasible way has been under discussion for a long time, mentioned in the meetings, reports, collaboration with SDSC, etc. Since last week it has moved to implementation.
Please follow in the meetings.
Your use case will be recorded and keep track as many others, in connection to this feature.

For testing you can keep passing the token since it works for you.

[ferrigno]

Not sure if it works, the service never finished when started from the frontend, but I cannot see the execution, so I cannot debug (this is another development, so I will wait patiently).
I understood that management of authentication and credentials is the main focus of the development with SDSC together with the connection to the HPC service (which is linked). However, if it arrives to a solution in December 2024, we might have wanted other paths.

[volodymyrss]

What is linked is not just about HPC storage, it's not what it says in the ticket, project, and RFC. Since you are not up to date on this aspect of the project, we can discuss it separately.
The credentials injection relevant for MMODA federation are not going to wait till December 2024.

Anyway, is it urgent for you? What is the time scale?

[ferrigno]

It is OK, I can wait:

• first I need to test services to run and for this I need to see the notebook output to understand where there is a problem
• Then I need to finalize the outputs, for now, they are just a guess, not having a successful run
• Then, it would be nice that the labels oda:label are implemented also in MMODA, prameter name with underscores are ugly
• Then, it would be very confusing for a general user to see a token to enter as a parameter and derive it from maybe another instance of the same platform, so this aspect should be solved before publication of these "expert mode" notebooks

[dsavchenko]

• first I need to test services to run and for this I need to see the notebook output to understand where there is a problem

Notebook output IS already implemented. You don't see any output because of the frontend issue, it gets stuck with progress-bar window in case of non-successfull error code from dispatcher (Some of them? Providing some tests for this issue is still in my todo). In this particular case, there is 403 "Not authorised" response.
I suspect, the reason is that in your workflows the input parameter is named "token" and it masks the actual token, which is appended with the same name to the request.

So just rename this parameter somehow and see if it helps.

• Then I need to finalize the outputs, for now, they are just a guess, not having a successful run

• Then, it would be nice that the labels oda:label are implemented also in MMODA, prameter name with underscores are ugly

What will be easy for now is to make some string transformation in the tab generator, e.g. Capitalise the labels and replace underscores with spaces. It will look better in most cases.

• Then, it would be very confusing for a general user to see a token to enter as a parameter and derive it from maybe another instance of the same platform, so this aspect should be solved before publication of these "expert mode" notebooks

With token as input parameter, it wouldn't be complicated to make this form field hidden and populate with the token from user session (Only if token key is shared between instances, of course).

[volodymyrss]

• Then I need to finalize the outputs, for now, they are just a guess, not having a successful run
• Then, it would be nice that the labels oda:label are implemented also in MMODA, prameter name with underscores are ugly

What will be easy for now is to make some string transformation in the tab generator, e.g. Capitalise the labels and replace underscores with spaces. It will look better in most cases.

Indeed, this could be useful (oda-hub/frontend-tab-generator#28) .

Then there is #53

• Then, it would be very confusing for a general user to see a token to enter as a parameter and derive it from maybe another instance of the same platform, so this aspect should be solved before publication of these "expert mode" notebooks
  With token as input parameter, it wouldn't be complicated to make this form field hidden and populate with the token from user session (Only if token key is shared between instances, of course).

It should be just called differently token it's to access to access different platform with difference capacities.
Also we can not really share the sort of secrets necessary for this between platforms so the token will be different.

[ferrigno]

I can change the name of the token parameter in the notebooks for testing, but if one has to fill the token manually from the UNIGE instance into the French instance the service becomes unusuable. We will need to group all workflows relative to an instrument to a single instance as it would be too confusing for a user to get token for INTEGRAL in Geneva, token for CTA in Lausanne, token for Antares in Paris ... giving stupid examples.

[volodymyrss]

I can change the name of the token parameter in the notebooks for testing, but if one has to fill the token manually from the UNIGE instance into the French instance the service becomes unusuable. We will need to group all workflows relative to an instrument to a single instance as it would be too confusing for a user to get token for INTEGRAL in Geneva, token for CTA in Lausanne, token for Antares in Paris ... giving stupid examples.

I don't know what you are trying to say here, I thought we discussed above that ODA token injection (similarly to other credentials and secrets) will be implemented (before December 2024).

[dsavchenko]

You don't see any output because of the frontend issue, it gets stuck with progress-bar window in case of non-successfull error code from dispatcher (Some of them? Providing some tests for this issue is still in my todo).

I deployed the latest frontend, and it seems this issue is fixed there. Now the error is clearly returned.
I will deal with this inconvenience with token parameter name in plugin #87, but meanwhile you can just rename

[ferrigno]

Thanks Denis. Volodymr, let's talk about this on another day, we are going in round here with my poor understanding of things.

[dsavchenko]

For the reference:

Simply adding token parameter doesn't work oda-hub/frontend-tab-generator#33

[volodymyrss]

@okolo can we add a term for specifying dependency on another MMODA?