openvsx
openvsx copied to clipboard
eclipse
Switch authentication from current OAuth to use Keycloak
Within the Eclipse Foundation, we are in the process of slowly deprecating the usage of the OAuth client provided through the Drupal website and are switching to Keycloak for OIDC services. We will want to change over to use Keycloak for this service, and align with the upstream API change to consume the new authentication source.
For more info, see https://gitlab.eclipse.org/eclipsefdn/it/api/eclipse-openvsx-api/-/issues/38
Hi @amvanbaren! We have an internal objective to move this to not use Drupal OAuth by end of June. Is this something that can be accomplished in that time period? What is the best time for us to work on this together. I've done what should be the work on the EF API side of it, but it is untested with the binding API, so I should be able to jump on this whenever you are ready outside the week of June 16th.
Ok, do we need to make changes in the EclipseService?
Among other things, probably yes. I suspect the class that needs to change most is the TokenService as that sources oauth2 tokens from accounts.eclipse.org, which will need to be switched to auth.eclipse.org. We'll likely want configuration for the base URL, realm name, along with the normal creds so we can swap between auth and auth-staging between environments
@amvanbaren how does the time line look on this? Let me know if you need a credential to test locally, as we should be able to get staging on our side running with Keycloak for you to do some real testing.
Ok, do we need to make changes in the EclipseService?
Among other things, probably yes. I suspect the class that needs to change most is the TokenService as that sources oauth2 tokens from accounts.eclipse.org, which will need to be switched to auth.eclipse.org. We'll likely want configuration for the base URL, realm name, along with the normal creds so we can swap between auth and auth-staging between environments
It uses the spring.security.oauth2.provider.eclipse.token-uri from application.yml
https://github.com/eclipse/openvsx/blob/3923d25f5bd4d3497da2117962b40e6bd5d7799a/server/src/main/java/org/eclipse/openvsx/eclipse/TokenService.java#L112-L118
@autumnfound You can make the changes in https://github.com/EclipseFdn/open-vsx.org/blob/main/configuration/application.yml and test it.
@amvanbaren Can you please verify that everything is working correctly on the Open VSX application, rather than asking @autumnfound?
While we're responsible for the authentication server, we need support from the application developer to ensure it’s properly integrated and functioning as expected.
@chrisguindon I'm looking forward to a PR with the new spring.security.oauth2.client.registration.eclipse configuration.
On staging.open-vsx.org, I got the following error when attempting to load my profile:
Error
Request for retrieving user profile failed: 403 Forbidden: [no body]
So it looks like it's at least retrieving credentials, but they aren't being accepted on staging. Does staging.open-vsx target api-staging still, or was it reverted to point at production? I'm pretty sure at some point we had switched it, but it would explain the error we're seeing.
https://github.com/EclipseFdn/open-vsx.org/blob/ef028976583acbf747fe2be6c497d769b8924ad6/configuration/application.yml#L53-L63
2025-06-09T19:39:39.781Z ERROR [openvsx-server,506e688f7a788c0ebb4f6f6c55773107,f87e4dd3e0aed40f] 1 --- [openvsx-server] [qtp1455940305-28] [506e688f7a788c0ebb4f6f6c55773107-f87e4dd3e0aed40f] o.e.openvsx.eclipse.EclipseService : Get request failed with URL: https://api.eclipse.org/openvsx/profile
org.springframework.web.client.HttpClientErrorException$Forbidden: 403 Forbidden: [no body]
at org.springframework.web.client.HttpClientErrorException.create(HttpClientErrorException.java:109)
at org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:183)
at org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:137)
at org.springframework.web.client.ResponseErrorHandler.handleError(ResponseErrorHandler.java:63)
at org.springframework.web.client.RestTemplate.handleResponse(RestTemplate.java:942)
at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:891)
at org.springframework.web.client.RestTemplate.exchange(RestTemplate.java:730)
at org.eclipse.openvsx.eclipse.EclipseService.getUserProfile(EclipseService.java:259)
@amvanbaren yeah, I had seen a 403 from the service about the profile and figured it was that endpoint. I grabbed the client + secret used by the open-vsx spring app and tested that call through a REST client, and was able to confirm the client can access that endpoint manually. At this point, I can confirm it's something wrong in the open-vsx.org spring app that isn't communicating with the EF API properly.
Also RE the configs, I meant this value https://github.com/EclipseFdn/open-vsx.org/blob/ef028976583acbf747fe2be6c497d769b8924ad6/configuration/application.yml#L166. From what I understand, this had been set to hit api-staging on staging.open-vsx.org via the server configs, which is the correct setup. If that is hitting api.eclipse.org instead, then this error is caused by that, as it uses a different auth server.
@amvanbaren I've done some testing, and it looks like I've gotten the server running with Keycloak fully on staging! I worked with @heurtematte to get the internal application configurations updated with the staging values. In the future, we won't need to do pushes to the open-vsx.org site configurations to link to production any more!
I've done testing to load the user + check the publisher agreement, and it seems to work. Are there any functions otherwise that you would need to test? Once we validate that everything still works, we can plan a time to do the production update and close this out!
In the future, we won't need to do pushes to the open-vsx.org site configurations to link to production any more!
You moved the configuration to DEPLOYMENT_CONFIG?
In the future, we won't need to do pushes to the open-vsx.org site configurations to link to production any more!
You moved the configuration to
DEPLOYMENT_CONFIG?
I worked with Seb to get the configurations embedded into the appropriate environments. I'm not super sure on the exact details, but @heurtematte will likely be able to give you a better answer for that. We're at a work conference this week, so we'll be slow in responding, just as a heads up.
I confirm that the data is stored in a Kubernetes secret containing a configuration.yml file, which is loaded via the DEPLOYMENT_CONFIG environment variable.
@heurtematte Only the secret or also the endpoints? Meaning, can spring.security.oauth2.client.registration.eclipse.*, spring.security.oauth2.client.provider.eclipse.* and ovsx.eclipse.* be removed from https://github.com/EclipseFdn/open-vsx.org/blob/main/configuration/application.yml?
I've done testing to load the user + check the publisher agreement, and it seems to work. Are there any functions otherwise that you would need to test? Once we validate that everything still works, we can plan a time to do the production update and close this out!
Revoking a publisher agreement and then signing the publisher agreement again results in a 409 (Conflict).
Only the secret or also the endpoints?
Also the endpoint for staging env. staging url is different.
I've done testing to load the user + check the publisher agreement, and it seems to work. Are there any functions otherwise that you would need to test? Once we validate that everything still works, we can plan a time to do the production update and close this out!
Revoking a publisher agreement and then signing the publisher agreement again results in a 409 (Conflict).
The 409 is unrelated to the authentication switch. The webui retries the request because the first request times out (the server needs to re-activate 500 extensions).
No further testing needed.
The 409 is unrelated to the authentication switch. The webui retries the request because the first request times out (the server needs to re-activate 500 extensions).
No further testing needed.
That's great to hear! I can work with @heurtematte to update the secrets in the DEPLOYMENT_CONFIG later this week. Other than the overridden configuration properties, is there anything else we need to take into account before attempting the rollout? I just want to make sure that nothing else was updated outside of the ticket that might impact the rollout!
Don't forget to move the issuer-uri to DEPLOYMENT_CONFIG as well. Other than that there are no changes that impact open-vsx.org: https://github.com/EclipseFdn/open-vsx.org/compare/production...main
Don't forget to move the issuer-uri to DEPLOYMENT_CONFIG as well. Other than that there are no changes that impact open-vsx.org:
Sounds good, that was the plan yeah! I plan on doing the prod release tomorrow at 9:30am EDT (1:30pm UTC), and I'll be testing what I can to ensure that we're stable. If there's any issues, I plan to immediately revert to maintain system uptime/integrity.
@amvanbaren can you jump on slack, we've been trying to reach out RE the deployment and some issues we're having.
Closing as the service now uses Keycloak successfully with only configuration updates and no changes needed to the base server code.