adds support for mongo-oidc

[Juan Tenorio Arzola (xolotlatoani)]

No description provided.

[Ilya Epelbaum (IlyaEp)]

Thanks for contributing! I’ll have another look after we address or discuss the current issues

[Juan Tenorio Arzola (xolotlatoani)]

Updated the PR. Sorry for the delay, I finally had time to come back to this.

[Mohammad Shabib (MohammadShabib)]

Ilya Epelbaum (@IlyaEp) can we get this to release ?

[Mohammad Shabib (MohammadShabib)]

and also thank you Juan Tenorio Arzola (@xolotlatoani)

[Juan Tenorio Arzola (xolotlatoani)]

Updated to use a random port, cache the tokens to re-use across sessions, and added a landing page for when the user completes the flow

[Ugur Cem Ozturk (ugurcemozturk)]

Enterprise user here, we have to use other platforms(MongoDB Compass) just because this feature is missing in Datagrip. Do you have a planned release date?
Thank you!

[Ilya Epelbaum (IlyaEp)]

Sorry for the long delay with the review

[Juan Tenorio Arzola (xolotlatoani)]

Updated to address comments

[Anvar Ramazanov (anvar-ramazanov)]

Hi, sorry for the long delay in getting back to you. I really appreciate your contribution and the effort you put into it. I’ve left a couple of comments as well, but overall I’m very grateful for your work. Thank you!

[Juan Tenorio Arzola (xolotlatoani)]

updated once more.

[Anvar Ramazanov (anvar-ramazanov)]

Let me also check how it works in IJ/DG, I'll try to get back as soon as I can

[Anvar Ramazanov (anvar-ramazanov)]

Juan Tenorio Arzola (@xolotlatoani) I tested the driver in DataGrip and the OIDC flow works overall, but I ran into one compatibility issue with the callback redirect URI.

Right now the driver uses a random local port for the OIDC callback. Some providers may not support wildcard matching for random redirect ports. I tested this with Keycloak, and it rejects the redirect URI unless the exact
callback port is registered.

I think it would be useful to add a setting like OIDC_CALLBACK_PORT, so users can configure a stable callback port when their IdP requires an exact redirect URI. We could keep the current random-port behavior as the default, or
consider a default fixed port such as 27097, which is also mentioned in the MongoDB OIDC workforce setup docs: https://www.mongodb.com/docs/manual/core/oidc/workforce/workforce-external-provider/#steps

UPD:
We should also consider SSL certificate handling for the Identity Server. Currently, the only option is to provide certificates via custom VM settings. It would probably be better to make this configurable and allow certificates to be loaded from the system trust store, rather than only from the current Java process configuration.

[Juan Tenorio Arzola (xolotlatoani)]

Juan Tenorio Arzola (Juan Tenorio Arzola (@xolotlatoani)) I tested the driver in DataGrip and the OIDC flow works overall, but I ran into one compatibility issue with the callback redirect URI.

Right now the driver uses a random local port for the OIDC callback. Some providers may not support wildcard matching for random redirect ports. I tested this with Keycloak, and it rejects the redirect URI unless the exact callback port is registered.

I think it would be useful to add a setting like OIDC_CALLBACK_PORT, so users can configure a stable callback port when their IdP requires an exact redirect URI. We could keep the current random-port behavior as the default, or consider a default fixed port such as 27097, which is also mentioned in the MongoDB OIDC workforce setup docs: mongodb.com/docs/manual/core/oidc/workforce/workforce-external-provider#steps

UPD: We should also consider SSL certificate handling for the Identity Server. Currently, the only option is to provide certificates via custom VM settings. It would probably be better to make this configurable and allow certificates to be loaded from the system trust store, rather than only from the current Java process configuration.

I added a new option OIDC_CALLBACK_PORT with a default value of 27097.

Also made the host dynamic based on a config flag that defaults to localhost. Some IdPs either set localhost or 127.0.0.1 and they treat those differently.

I had an issue with the new change that updated the java version to v21. I could not get Datagrip to load it. Is Datagrip being uptaded to use java 21?

[Anvar Ramazanov (anvar-ramazanov)]

Juan Tenorio Arzola (@xolotlatoani) with which version of DataGrip did you test? AFAIK it should be OK with the last one. Btw are you ok if I add some code to better handle cache and handle certificates for https in IDE? But I probably do in another PR.

Now the PR looks good to me, but the one thing still annoy me. On Windows it could be a problem to use cmd.exe with URLs that contains &. In cmd & is a group command separator and redirecting to url looks like https://keycloak/.../auth?scope=openid+offline_access&response_type=code&redirect_uri=http%3A... could be broken. We probably should use another approach with rundll32.exe. I'll check it thoroughly and come back with answer

[Juan Tenorio Arzola (xolotlatoani)]

Juan Tenorio Arzola (Juan Tenorio Arzola (@xolotlatoani)) with which version of DataGrip did you test? AFAIK it should be OK with the last one. Btw are you ok if I add some code to better handle cache and handle certificates for https in IDE? But I probably do in another PR.

Now the PR looks good to me, but the one thing still annoy me. On Windows it could be a problem to use cmd.exe with URLs that contains &. In cmd & is a group command separator and redirecting to url looks like https://keycloak/.../auth?scope=openid+offline_access&response_type=code&redirect_uri=http%3A... could be broken. We probably should use another approach with rundll32.exe. I'll check it thoroughly and come back with answer

NVM, I ended up changing the VM home path in the driver to get my recent changes working. I'm totally good with whatever tweaks or changes you guys suggest!

As for the wrappers, I really wanted to use them with Java desktop actions instead of relying on cmd or open commands. Since they kept failing for me, I just left the current approach as a backup. Happy to collaborate on getting the wrappers working if you have any tips.