Re: Infrastructure | Login to openqa.gnome.org with gitlab.gnome.org (#637)



Title: GitLab

Sam Thursfield commented:

Spent a while trying to get this to work today, here's what happened.

OpenID Connect is a superset of OAuth2, and so OpenQA OAuth2 backend can authenticate against Keycloak OpenID Connect provider. In theory. This is working at http://openqa.qa.codethink.co.uk/ already.

https://auth.gnome.org/ uses Keycloak and we configured a new 'openqa' application.

Login on openqa.gnome.org successfully redirects to auth.gnome.org, back to openqa.gnome.org/login, at which point we see an error: "User data returned by OAuth2 provider is insufficient"

The error comes from https://github.com/os-autoinst/openQA/blob/master/lib/OpenQA/WebAPI/Auth/OAuth2.pm#L82 and is triggered by return value of the https://auth.gnome.org/auth/realms/master/protocol/openid-connect/userinfo endpoint. OpenQA expects to find id (not configurable) and preferred_username (configurable) in the output, and doesn't.

Keycloak doesn't set id by default, but it can be configured to map one property to another. This is what happens in the Codethink instance and it works. In the Gnome instance, the id property is never sent - regardless which property it is mapped from (tried email, username, preferred_username).

OpenQA doesn't print debug logs here, but I modified the Perl code directly to add some. Specifically ./usr/share/openqa/lib/OpenQA/WebAPI/Auth/OAuth2.pm adding lines:

use OpenQA::Log qw(log_debug);
use Data::Dumper;

(at the top)

log_debug("TX result: " . Dumper($tx->res));
log_debug("Details: " . Dumper($details));

(just before line 82).

Also set logging.level = debug in the openqa.ini file. This is enough to dump the user data it receives, and see that there's no id field.

At this point we don't know why Keycloak isn't sending the field.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]