Open DickPostma opened 3 weeks ago
storing the MOLGENIS_OIDC_CLIENT_SECRET ( master key) as plain text in the db would be a security concern, if we want to move the oidc config form deployment config into the runtime config i would suggest to fetch it from a system like the vault. This setup to have a (optional) secure external key store would make the whole deployment config more complex, so i am not sure it would be worth it.
@connoratrug This story is written with hosting emx2 at externals without OPS in mind. (In our own network a vault connetion would be great) I understand the security risks, but you can get more options in place and let the customer decide.
If you store client-id and secret-id secured and encrypted in the DB would the first step and you can always put the second option ( environment ) in place.
Is your feature request related to a problem? Please describe. OIDC Configuration is setup on an system environment level. This is now an OPS or an system administrator tasks. Datamanagers or Application managers should have the option to change or add OIDC details. After installation Admins need OPS to change details. In the most cohorts this is an long and slow process.
Describe the solution you'd like An configurable option in the admin settings with:
MOLGENIS_OIDC_CLIENT_ID // the id for the molgenis instance as set in the authentication provider MOLGENIS_OIDC_CLIENT_SECRET // the client secret as set in the authentication provider (Password field so not visible to external users) MOLGENIS_OIDC_CLIENT_NAME // the client name as set in the authentication provider, defaults to MolgenisAuth MOLGENIS_OIDC_DISCOVERY_URI // location of authentication provider (with path to relevant service) MOLGENIS_OIDC_CALLBACK_URL // public available endpoint for molgenis service to handle the login action ( https://[public server location]/_callback, note the '_callback' is added by the molgenis server )
Additional context