Display an error message for blocked users

[tillprochaska]

Aleph includes an option to block individual users. Blocking users effectively makes it impossible for them to sign in. Right now, a generic authentication failure message is displayed when a blocked user tries to sign in. As we’re considering blocking user accounts that have been inactive for some time, we want to display a specific error message (incl. instructions on how to reactivate the account) when a user has been blocked.

Implementation considerations

• Most of the diff in this PR comes from new tests for the existing password and OAuth authentication flows.
• The new test cases for the OAuth flow are as close the the real flow as possible, only mocking one request to the identity provider to fetch OAuth tokens.
• The main change in the actual authentication logic is a refactoring: Before, both the password login handler and he OAuth handler returned either a Role record in case of successful authentication or None in case of an authentication error. This makes it difficult to handle different authentication errors at a higher level in the actual API routes. Now, these handlers raise different exceptions depending on the authentication error so we can handle them differently in the API routes. Also take a look at the individual commit messages which have a few more details.

How to test this locally

In order to test the password flow, just create a password user in your development environment and manually set the is_blocked column in the role table.

Testing the OAuth flow is slightly more complex and requires running an OpenID Connection provider in your development environment. Here’s a draft of a guide on how to set up a Keycloak instance for testing in your development environment:

Expand

How to Set Up an Identity Provider for Development

When making changes to the OAuth authentication flow in Aleph, it can be helpful to test changes against a real identity provider. This guide describes how to run the Keycloak identity provider in your local development environment and how to configure Aleph accordingly.

This guide describes how to set up Keycloak in a development environment. If you want to configure a production Aleph instance to use Keycloak as an identity provider, please refer to our operations guide.

Run and configure Keycloak

The official Keycloak documentation provides detailed instructions on how to run Keycloak using Docker. You can follow these instructions for the most part. However, you will have to make a few minor changes:

The default port used in the Keycloak documentation is 8080. In an Aleph development environment that port is already in use for the Aleph UI. Adjust the port mapping for the Keycloak container to use a different port:

docker run -p "8888:8080" -e "KEYCLOAK_ADMIN=admin" -e "KEYCLOAK_ADMIN_PASSWORD=admin" quay.io/keycloak/keycloak:23.0.1 start-dev

After creating a new realm in the Keycloak admin console, set the "Frontend URL" setting to http://localhost:8888. This is necessary to ensure that Aleph redirects you to the correct URL during the authentication flow.

When creating a new client using the Keycloak admin console, change the following settings:

Setting	Value
Client authentication	Enabled
Valid redirect URIs	http://localhost:8080/api/2/sessions/callback
Valid post logout redirect URIs	http://localhost:8080/

After creating a new client using the Keycloak admin console, switch to the "Credentials" tab and take note of the client secret.

Configure Aleph

Finally, you need to adjust Aleph’s configuration to use your local Keycloak instance instead of the default password authentication flow.

Set the following Aleph configuration options:

Configuration option	Value
ALEPH_OAUTH	true
ALEPH_OAUTH_KEY	myrealm
ALEPH_OAUTH_SECRET	Client secret from previous step
ALEPH_OAUTH_METADATA_URL	http://host.docker.internal:8888/realms/myrealm/.well-known/openid-configuration
ALEPH_PASSWORD_LOGIN	false

Restart Aleph, visit the Aleph UI at http://localhost:8080, and click on the "Sign in" button in the navigation bar to test the authentication flow.

Todos

• Make blocked message and link configurable via environment variables

Configuration options

This PR adds three new configuration options to customize the contents of the error message per instance:

• ALEPH_ROLE_BLOCKED_MESSAGE (This defaults to just "Your user account has been deactivated")
• ALEPH_ROLE_BLOCKED_LINK (Defaults to None, i.e. no link is displayed.)
• ALEPH_ROLE_BLOCKED_LINK_LABEL

Screenshot

Here’s an example of the popup displayed when a user is redirected back from the identity provider. The message, button label and button link are configurable (see above).

[tillprochaska]

Cherry picked from 87a91c0

[catileptic]

I couldn't stop anything eyebrow-raising. LGTM?