You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need to have the possibility to create service tokens (used for syncronisation from MXCuBE for instance). These could be the using the same JWT token system as user tokens but with a longer expiration time, defined at creation.
The only difference is that it should not contain a personId as it should not be linked to a person (see if setting it to None or some dummy value like -1 would cause problems?)
These tokens could be created with a new route POST /auth/service by a logged in user with required permission (create_service_token) who specifies the required information:
service name
permissions
expiration time
The text was updated successfully, but these errors were encountered:
We need to think about this, this has never been implemented properly in java or synchweb. We probably want a full OAuth system, with token and refresh system. Certainly shouldn't have long validity tokens.
Before jumping in heavy developments we could organize a meeting to make the authentication/authorization mechanism clear and double check that all the use cases are on the table.
Just some questions came to my mind:
Do we really need a separate mechanism for the service taking into account that a service might be considered as a user with specific permissions?
How the downstream process (workflows, analysis...) will authenticate the requests? Re-authentication? Token propagation?
In the client side, how/where do the credentials/api token will be stored?
Is it envisagable a non-public py-ispyb instance dedicated to data ingestion (with a single service authentication mechanism deployed) and a publicly exposed instance for the UI/users?
We need to have the possibility to create service tokens (used for syncronisation from MXCuBE for instance). These could be the using the same JWT token system as user tokens but with a longer expiration time, defined at creation.
The only difference is that it should not contain a
personId
as it should not be linked to a person (see if setting it toNone
or some dummy value like-1
would cause problems?)These tokens could be created with a new route
POST /auth/service
by a logged in user with required permission (create_service_token
) who specifies the required information:The text was updated successfully, but these errors were encountered: