Replace Drupal login with Keycloak single sign-on (SSO) is not working

I was just investigating this.

First of all, the KeycloakService doesn't work anymore since OpenID Connect module switched from configuration to config entities. Instead of loading openid_connect.settings.keycloak config, it should load an active keycloak client like in OpenIDConnectLoginForm::submitForm

    // Loading an active keycloak client.
    $clients = $this->entityTypeManager->getStorage('openid_connect_client')->loadByProperties(['plugin' => 'keycloak', 'status' => 1]);
    $client = reset($clients);

    // From there you can access the settings
    $settings = $client->getPluginCollections()['settings'];
    // or the plugin.
    $plugin = $client->getPlugin();

Same for the KeycloakController, it should load an active client and then execute the same code as OpenIDConnectLoginForm::submitForm. But when I tried this solution I got an exception :

LogicException: The controller result claims to be providing relevant cache metadata, but leaked metadata was detected. Please ensure you are not rendering content too early. Returned object class: Drupal\Core\Routing\TrustedRedirectResponse

This needs more investigating and test, but I don't have time to do so, hope this help.

There is another issue open for this: #3107127: Can't get SingleSignOut to work
Where some more discussion about the topic happened. That one is also part of the roadmap to getting 2.x stable.

@hiralshah1991 Your problem is this one:
https://www.drupal.org/project/keycloak/issues/3391108

in combination with this one:
https://www.drupal.org/node/2638686

The problem here is the OPENID_CONNECT_CONFIG_NAME in combination with a missing enabled config as queried in KeycloakService::isEnabled(). I assume we have to change the implementation of KeycloakService::isEnabled() to query the status config property. See attached 3382665-fix-config-enabled-flag.diff.

Ran into another problem in the KeycloakController where the old setting is used. Here's the fix: 3382665-7-fix-config-enabled-flag.diff

@hiralshah1991 I fixed your last problem directly in Keycloak without hacking core.

https://www.drupal.org/project/keycloak/issues/3396331

As I said earlier, OpenID Connect module module changed the way it stores configuration (from config to config entities) + The user can chose the configuration id.

So hard coding "openid_connect.client.keycloak" as #6 does is not the way to go I think. First of all, the controller would be aware of which config is actually used (e.g., putting the id of the config into the route path). This way we can give it to the service to use the right config.

I don't know in which case there can be multiple keycloak config on the same site, but It's actually possible and can be a use case (like multiple realms maybe ?).

An other idea: When the admin checks the option to replace the login page, then load a keycloak config with that option but in an undefined order (+ document this behavior) and use it.

I don't know in which case there can be multiple keycloak config on the same site, but It's actually possible and can be a use case (like multiple realms maybe ?).

Example:
- Agency X using keycloak for all their Devs
- Customer X using keycloak for all their users

It's a valid use case which we actually have on some projects. I've actually also worked once for a customer where they had two keycloak instances. One for their internal employees, and one for their external users/clients/customers.

An other idea: When the admin checks the option to replace the login page, then load a keycloak config with that option but in an undefined order (+ document this behavior) and use it.

Yeah, I guess we need to perhaps have the option to set a default one for when the replace drupal login option is selected. The others of course still need to be accessible by their own path on the site.

The issue https://www.drupal.org/project/keycloak/issues/3390391 implements support for multiple keycloak configurations and adds a global setting to choose which of the keycloak configurations that should be used to override the drupal login form.

#7 give me the next error

Symfony\Component\Routing\Exception\InvalidParameterException: Parameter "openid_connect_client" for route "openid_connect.redirect_controller_redirect" must match "[^/]++" ("" given) to generate a corresponding URL. in Drupal\Core\Routing\UrlGenerator->doGenerate() (line 209 of core/lib/Drupal/Core/Routing/UrlGenerator.php).

I have fixed #14 by changing Drupal\keycloak\Controller\KeycloakController::login() as following:

public function login() {
    $this->session->saveDestination();
    $client_name = 'keycloak';

    $config = $this->config('openid_connect.client.keycloak');
    $settings = $config->get('settings');
    $pluginCollection = new OpenIDConnectClientCollection($this->pluginManager, $client_name, $settings, $config->get('id'));
    $client = $pluginCollection->get($client_name);

    $scopes = $this->claims->getScopes();
    $_SESSION['openid_connect_op'] = 'login';
    return $client->authorize($scopes);
  }

With this change, the client_id is set and the redirect is working.

Works with applying the patch form #7 and #3396331: LogicException when redirecting to Keycloak (#8)

Now, the next error appears: "Failed to start the session because headers have already been sent by "/app/vendor/symfony/http-foundation/Response.php" at line 1315."

See #3396331-9: LogicException when redirecting to Keycloak

I have added the changes from #15 to the patch from #7. It works with the latest 2.2.x branch.

Attach interdiff between #7 and #17.

After some investigation, it looks like that #3396331: LogicException when redirecting to Keycloak is not needed. The MR calls $request->send() from there, which is done by Drupal itself.

MR43 works for me. Can anyone check it?

Redirect with MR43 seems to work properly for me with openid_connect 3.0.0-alpha5. But with the new alpha6 that came out in the meantime, I'm getting a new error: You have requested a non-existent service "openid_connect.openid_connect".

#3506932-02: non-existent service "openid_connect.openid_connect" after update

@profi248, thanks for reporting, I'll notify the openid_connect folks that alpha6 caused this : You have requested a non-existent service "openid_connect.openid_connect"

@profi248 , please test again alpha6 but apply this patch on openid_connect alpha6, possibly resolve the issue you reported.

https://www.drupal.org/files/issues/2025-02-17/openid_connect-revert-346...

@profi248, update your build so that you get the full alpha6

now before you start using the site, run the hook updates

Ex:
drush updb -y;

or

visite update.php

Did the schema updates run without error?

Now test again.

@joseph.olstad thanks for the reply.

This patch to openid_connect didn't apply for me, so I tried using MR144 from https://www.drupal.org/project/openid_connect/issues/3462532 instead. That, along with MR43 patch to keycloak did indeed fix the redirect problem, even on alpha6.

I also had to reinstall my local dev site after database migrations didn't work, but that seems to be a problem of me doing this on the same install before. When I started with a fresh install on keycloak 1.8.0 and openid_connect 1.4.0 and then ran the migrations, there were no issues.

MR43 has been working well for me on our site. It would be great if we could get it merged into upstream. Let me know if you need any more testing.

We have been using the changes from the MR for some time now without any problems.
However, setting my own MR as RTBC feels wrong :).

Can someone review it and comment accordingly?

Thank you very much.

https://www.drupal.org/project/keycloak/releases/2.2.2

I updated the issue credits. Thanks everyone