Localize client authentication with d.o infrastructure

@hestenet - I am going to work with @sanduhrs and @fgm to set up access to our development system on cloud-iam so that they can get this ready. Both have already signed contributor agreement and NDA.

I will coordinate this with @heddn who is doing primary development

Ah, I think understand what we're doing here. We're wanting to authenticate from random drupal sites to submit (as authenticated d.o users) translations. In the case, the ability to authenticate using keycloak is very much a possibility. Feel free to reach out on slack (heddn) and I can orient you guys on the sandbox environment we have setup.

While we are working on the actual migration of d.o users to keycloak, might I suggest spinning up a playground: https://www.keycloak.org/getting-started/getting-started-docker? Then wire up l10n_client to this generic keycloak instance, figure out what is needed and propose that solution to all of us. Our setup of keycloak is very traditional. Not much special (yet) added to the out of the box setup. Developing with a localdev is going to be way more efficient then using any server or cloud hosted solution too. Just document the setup steps proposed here.

Keycloak may or may not be the solution here. I’m interpreting this as needing something to manage API keys that can be used for authenticating write access only this localization service.

Full access to the localize site as the user might be okay, it is a bit of extra access, but there is not a lot more going on in the site. Full access as a user who can approve/etc translations might not be intended.

We certainly don’t want to be using keys which have access to authenticate as the user everywhere else on *.drupal.org. That would be unnecessary risk.

Ah, I think understand what we're doing here. We're wanting to authenticate from random drupal sites to submit (as authenticated d.o users) translations.

Yes - That's the idea.

We certainly don’t want to be using keys which have access to authenticate as the user everywhere else on *.drupal.org. That would be unnecessary risk.

Yes - I hope we find a solution with have access-tokens/api-keys that can be used for the contribution endpoints authentication only.

Btw. we started working on the server endpoints: https://www.drupal.org/project/l10n_server/issues/3395508 📌 New endpoints for l10n_client_contributor Needs review
And the corresponding adjustments in the l10n_client: https://www.drupal.org/project/l10n_client/issues/3395327 📌 Replace xmlrpc for new localize.drupal.org Needs work

After talking with @drumm at DrupalCon:

We can create a "secret" or "token" filed in the user profile in localize.drupal.org, and then use that as a way to allow other Drupal sites to communicate with the localize.drupal.org.

We can use modules like https://www.drupal.org/project/field_encrypt → to encrypt the value in the database. Ideally, users can regenerate or change that "secret" when they want and that's what they will use to post translations to localize.drupal.org.

I guess we'll need to create a plugin (https://git.drupalcode.org/project/l10n_server/-/tree/3.0.x/l10n_remote) or submodule (?) to read the token, try to find the user, and the do the rest once the user is validated.

guiu.rocafort.ferrer → made their first commit to this issue’s fork.