"The user profile feature is now enabled by default." [1]

[1] https://www.keycloak.org/docs/24.0.2/upgrading/#user-profile-changes

Registration has been disabled since 2023-07-09, so the code should have
been updated a long time ago.

As announced[2][3] the bugtracker has been migrated to gitlab, so
bugs.a.o can be decommissioned and replaced with a static copy[1](to
avoid link rot).

[1] https://gitlab.archlinux.org/archlinux/bugs-archive/
[2] https://archlinux.org/news/bugtracker-migration-to-gitlab-completed/
[3] https://lists.archlinux.org/hyperkitty/list/arch-dev-public@lists.archlinux.org/thread/WYXDTJ3TR2DWRQCDZK44BQDH67IDVGTS/

Fix #550
Fix #551

The form action RegistrationProfile has been removed in Keycloak 23.

Relevant information from the upgrading guide [1]:

> The validation of user attributes as well as creation of the user
> including all that user’s attributes is handled by
> RegistrationUserCreation form action and hence RegistrationProfile
> is not needed anymore.

[1] https://www.keycloak.org/docs/23.0.0/upgrading/#removed-registrationprofile-form-action



Co-authored-by: Kristian Klausen <kristian@klausen.dk>

Our free plan no longer supports 60-second interval for monitors.

We have a few staff and users who prefer using a alias/mononym, so let's
make it optional.

Since our custom Keycloak theme does not use v3[1][2] of the account
console yet, it is not aware that the last name is optional, so
unfortunately the user cannot change "personal info" in the account
console without also specifying the last name. This only affects the
account console, the initial user configuration can be done without
specifying a last name.

[1] https://gitlab.archlinux.org/archlinux/keycloak-archlinux-theme/-/blob/238889fb36d512f0baa328fad00531ef53c14c1f/lib/src/main/resources/theme/archlinux/account/theme.properties#L1
[2] https://www.keycloak.org/2023/04/keycloak-2110-released#_experimental_account_console_version_3

Ref #518

This reverts commit 903129d4

With the release of keycloak-metrics-spi 3.0.0 they added support
for Keycloak > 21.x [1]

[1]: https://github.com/aerogear/keycloak-metrics-spi/pull/157



Resolve: #499

Signed-off-by: Leonidas Spyropoulos <artafinde@archlinux.org>

This syncs the lock file with the latest change where we switched the
provider for uptimerobot

Levente Polyak authored 1 year ago and Levente Polyak committed 1 year ago

In commit d31f8404 we changed the
terraform provider for uptimerobot. Reflect this change in the terraform
lock file and provider version declaration.

Levente Polyak authored 1 year ago and Levente Polyak committed 1 year ago

Previously we have declared explicit resources for the roles under the
root. This lead to the desired groups getting created twice, once via
toSet of the package maintainer team and once per resource under the
root.

Furthermore remove the package maintainer roles, currently we do not
need any roles to define permissions. We can simply use the groups to
easily assign users into. Those group assignments can be queries for
example by gluebuddy to act upon or queried by a saml client.

Fixes 941563f2

Leonidas Spyropoulos authored 2 years ago and Levente Polyak committed 1 year ago

Signed-off-by: Leonidas Spyropoulos <artafinde@gmail.com>

[1] https://github.com/keycloak/keycloak/pull/15746

Fix #501

https://blog.uptimerobot.com/december-2022-we-are-introducing-sub-users-and-new-plans/



Signed-off-by: Leonidas Spyropoulos <artafinde@archlinux.org>

It's incompatible with Keycloak 21.

Re-enabling of metrics is tracked in #499.

[1] https://github.com/aerogear/keycloak-metrics-spi/issues/155

Signed-off-by: Leonidas Spyropoulos <artafinde@archlinux.org>

Fix #475

From [1]: "By default, the new Quarkus distribution removes /auth from
           the context-path."

[1] https://www.keycloak.org/migration/migrating-to-quarkus

Set the base_path provider attribute to "/auth" until we move the /auth
endpoint to be served from the root of https://accounts.archlinux.org/.

The buildbot POC wants to use Keycloak for user authentication. The
client is public, because it doesn't make sense to have a client secret,
which can't be kept under wrap anyway (it would need to be shipped with
the CLI[1]).

[1] https://gitlab.archlinux.org/foxboron/buildctl

When signing into GitLab, opting to create a new keycloak account
results in being able to sign into GitLab without setting up OTP.

Since any subsequent login will require configuring OTP, it seems
well advised to prompt for it as part of the registration process.

OpenID clients:
- 'use_refresh_tokens' set to false to preserve the values on live
- 'backchannel_logout_session_required' implicitly changed to true
  for the 'grafana_openid_client' and 'openid_gitlab' clients

SAML client (GitLab):
- 'front_channel_logout' set to false to preserve the live setting

Jelle van der Waa authored 2 years ago and Levente Polyak committed 2 years ago

Signed-off-by: Levente Polyak <anthraxx@archlinux.org>

Kristian Klausen authored 3 years ago and Jelle van der Waa committed 3 years ago

We are onboarding "Project Maintainers" now[1].

[1] https://lists.archlinux.org/private/staff/2022-February/000881.html

The gluebuddy client is required for gluebuddy to retrieve users and
groups membership without being able to change other keycloak data. The
realm-management roles cannot be assigned yet via keycloak as it does
not know about the roles and realm-management client.

Now that misc/get_key.py checks if the vault file passed to it exists,
we cannot pass paths only resolvable from the root directory. Instead,
use paths that make sense relative to the current directory and avoid
calling chdir when loading the vault file.

Fixes: 77542146 ("Rewrite get_key.py to use click instead of typer")

Thorben Günther authored 3 years ago and Kristian Klausen committed 3 years ago

This reverts commit 649568e7 ("Restrict Grafana access to Arch Linux
Staff group on Keycloak (fixes #151)").

Add our uptimerobot to terraform so it's managed in code and we can
easily extend it. This currently only adds our to be monitored sites and
leaves the status page as is now.

Deleting resources on uptimerobot will cause terraform unable to run
see: https://github.com/louy/terraform-provider-uptimerobot/issues/82

References: #209

Synapse only inspects the userinfo.

Closes #94

As our grafana now contains Loki logs, we don't want non devops to view
logs which potentially contain sensitive data. As Grafana does not have
a system to easily restrict data sources to roles we use Keycloak.