Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi,
At The Hyve (https://thehyve.nl/) we implemented the support of an OpenID Connect authentication in i2b2, which in our case is meant to be used by Glowing Bear (https://glowingbear.app/) and PIC-SURE (http://bd2k-picsure.hms.harvard.edu/). We tested the implementation with Keycloak as the OIDC server.
When users are configured to be authenticated this way, they can not login anymore with the existing clients. This is due to the fact that in the XML requests, the field containing the password is used to pass the (RS256-signed only) token obtained through OIDC by the client.
We figured out you might want to mainline this additional authentication possibility, which does not introduce incompatibilities with the others.
Best regards,
Mickaël Misbach
Some information and how-to about the changes:
The users must already exist in the i2b2 PM database, either existing users should be converted to be authenticated with OIDC, or created for this purpose.
Converting a user to be authenticated with OIDC requires to add several i2b2 parameters. This follows the usual i2b2 parameters pattern: they can be added at the user level, cell level, or project level. This also means that users authenticated with the original i2b2 process can coexist with users authenticated by OIDC. The only restriction is that the client must also support OIDC (which means that it cannot be used with the i2b2 webclient or workbench).
The parameters to add are the following:
Example of SQL inserts to configure the user "test" to be authenticated with OIDC: