v0.30.2

Changes

Hiqlite upgrade

Internally, hiqlite was updated to the latest stable version. This brings 2 advantages:

1. cluster.wal_ignore_lock has been removed completely. It is not necessary anymore, because hiqlite now can do proper cross-platform file locking and therefore can resolve all possible situations on its own. It can detect, if another hiqlite process is currently using an existing WAL directory and also do a proper cleanup / deep integrity check after a restart as well.
2. You have 2 additional config variables to configure the listen address for Hiqlites API and Raft server. This solves an issue in IPv6-only environments, because it used a hardcoded 0.0.0.0 before. You can now also restrict to a specific interface as well, which is beneficial for single instance deployments, or when you have lots of NICs.

[cluster]
# You can set the listen addresses for both the API and Raft servers.
# These need to somewhat match the definition for the `nodes` above,
# with the difference, that a `node` address can be resolved via DNS,
# while the listen addresses must be IP addresses.
#
# The default for both of these is "0.0.0.0" which makes them listen
# on all interfaces.
# overwritten by: HQL_LISTEN_ADDR_API
listen_addr_api = "0.0.0.0"
# overwritten by: HQL_LISTEN_ADDR_RAFT
listen_addr_raft = "0.0.0.0"

DB shutdown on unavailable SMTP

If the retries to connect to a configured SMTP server were exceeded, Rauthy panics, which is on purpose. However, the behavior has been updated slightly and it will now trigger a graceful DB shutdown before it executes the panic, which is just cleaner overall.

#1045

Bugfix

• A trigger for Backchannel Logout was missing for DELETE /sessions/{user_id} #1031
• state deserialization validation during GET /authorize was too strict in some cases. #1032
• The pre-shutdown delay should only be added in HA deployments, not for single instances. #1038
• The error messages in case of webauthn misconfiguration were not always very helpful. #1040

v0.30.1

Bugfix

• Fixed the encoding for EdDSA public keys. They have changed to b64 encoded DER format during the big JWT rework, when it should have been just raw bytes.
  #1018
• Added a short 3-second pre-shutdown delay to smooth out rolling releases inside K8s and also have a bit more headroom for bigger in-memory cache's replication
  #1019
• Small CSS fix to match the input width for group prefix login restriction for clients
  #1020
• In HA deployments, when the Leader was killed with an appended but not yet fully commited WAL log, there was a bug that made it possible that the log truncate would fail after restart and that the start-, instead of the end-offset would be adjusted. This has been fixed in hiqlite-wal in combination with a bump in patch version for openraft. If you run a HA cluster, you should upgrade immediately!.

v0.30.0

Breaking

Configuration Rework

You will need to migrate your whole configuration with this release.

Over the last months, Rauthy got so many new features and config options, that the old approach got a bit messy and hard to follow. Variable names needed to become longer over time to avoid overlap, and so on. Also, because of the way the application grew over the last years, configs, single static variables and some snippets existed in many places.

This needed to change.

You can still have a config file and overwrite (most) values via ENV vars, if you like, but at least the bare minimum must exist as a config file now. Even though ENV var are mostly now a security issue, they are by default not protected depending on the situation. The whole config file has been converted into a TOML file. This makes it possible to have different dedicated sections, shorter variable names again, and it's easier to organize and comes with an already existing, basic type-system and we can have arrays and typed primitives out of the box now.

The file has been renamed from rauthy.cfg to config.toml, and it must follow the toml syntax. I created a lookup table so everyone can easily convert their existing config with not too much work. The new config also is more verbose in terms of documentation and for each value (when it exists), the overwriting ENV var is mentioned directly above.

In some cases, you cannot overwrite with an ENV var, and in others, you can only do something with an ENV var. The situations when you can only do something via ENV are the ones, that will require you do remove the var immediately afterward anyway, like e.g. triggering a DB_MIGRATE_FROM, or do a new HQL_WAL_IGNORE_LOCK, and so on. But I guess it will become clear when you take a look at the lookup table. I also tried to make it more clear, which values are absolutely mandatory to set.

On the long run, this change, even though it was a huge PR with almost 12k lines changed, will make everything easier to maintain and the code a lot more approachable for newcomers. A nice side effect is, that I also optimized it a bit so that it requires a little bit less memory.

If anyone has issues with the config with this update, please open an issue and let me know. I did a lot of testing
and I think, everything is fine, but that many changed lines make it hard to keep track of everything, even though
this was necessary.

This is a tiny one, but the value for logging.log_level_access has been changed to all lowercase to match the other
log level values.

Lookup Table ENV var -> TOML value

Here you have the lookup table. When there is a - somewhere, it means that either no TOML or ENV var exists in that situation. The TOML path colum contains the parent table and the value name itself. For instance, when it says

access.userinfo_strict
access.sec_header_block    

It will look like this in the config.toml:

[access]
userinfo_strict = true
sec_header_block = true

For a complete documentation for each value, please take a look at the reference config from the book.

ENV VAR	TOML path	type	required
USERINFO_STRICT	access.userinfo_strict	bool
DANGER_DISABLE_INTROSPECT_AUTH	access.danger_disable_introspect_auth	bool
DISABLE_REFRESH_TOKEN_NBF	access.disable_refresh_token_nbf	bool
SEC_HEADER_BLOCK	access.sec_header_block	bool
SESSION_VALIDATE_IP	access.session_validate_ip	bool
PASSWORD_RESET_COOKIE_BINDING	access.password_reset_cookie_binding	bool
PEER_IP_HEADER_NAME	access.peer_ip_header_name	String
COOKIE_MODE	access.cookie_mode	String
COOKIE_SET_PATH	access.cookie_set_path	bool
TOKEN_LEN_LIMIT	access.token_len_limit	u32
AUTH_HEADERS_ENABLE	auth_headers.enable	bool
AUTH_HEADER_USER	auth_headers.user	String
AUTH_HEADER_ROLES	auth_headers.roles	String
AUTH_HEADER_GROUPS	auth_headers.groups	String
AUTH_HEADER_EMAIL	auth_headers.email	String
AUTH_HEADER_EMAIL_VERIFIED	auth_headers.email_verified	String
AUTH_HEADER_FAMILY_NAME	auth_headers.family_name	String
AUTH_HEADER_GIVEN_NAME	auth_headers.given_name	String
AUTH_HEADER_MFA	auth_headers.mfa	String
BACKCHANNEL_LOGOUT_RETRY_COUNT	backchannel_logout.retry_count	u16
BACKCHANNEL_DANGER_ALLOW_HTTP	REMOVED -> global http_client used now
BACKCHANNEL_DANGER_ALLOW_INSECURE	REMOVED -> global http_client used now
LOGOUT_TOKEN_LIFETIME	backchannel_logout.token_lifetime	u32
LOGOUT_TOKEN_ALLOW_CLOCK_SKEW	backchannel_logout.allow_clock_skew	u32
LOGOUT_TOKEN_ALLOWED_LIFETIME	backchannel_logout.allowed_token_lifetime	u32
BOOTSTRAP_ADMIN_EMAIL	bootstrap.admin_email	String
BOOTSTRAP_ADMIN_PASSWORD_PLAIN	bootstrap.password_plain	String
BOOTSTRAP_ADMIN_PASSWORD_ARGON2ID	bootstrap.pasword_argon2id	String
BOOTSTRAP_API_KEY	bootstrap.api_key	String
BOOTSTRAP_API_KEY_SECRET	bootstrap.api_key_secret	String
HQL_NODE_ID_FROM	cluster.node_id_from	"k8s"	x *1
HQL_NODE_ID	cluster.node_id	u64	x *1
HQL_NODES	cluster.nodes	[String]	x
HQL_DATA_DIR	cluster.data_dir	String
HQL_FILENAME_DB	cluster.filename_db	String
HQL_LOG_STATEMENTS	cluster.log_statements	bool
-	cluster.prepared_statement_cache_capacity	u16
HQL_READ_POOL_SIZE	cluster.read_pool_size	u16
HQL_LOG_SYNC	cluster.log_sync	String
HQL_WAL_SIZE	cluster.wal_size	u32
HQL_CACHE_STORAGE_DISK	cluster.cache_storage_disk	bool
HQL_LOGS_UNTIL_SNAPSHOT	cluster.logs_until_snapshot	u64
HQL_SHUTDOWN_DELAY_MILLS	cluster.shutdown_delay_millis	u32
HQL_TLS_RAFT_KEY	cluster.tls_raft_key	String
HQL_TLS_RAFT_CERT	cluster.tls_raft_cert	String
-	cluster.tls_raft_danger_tls_no_verify	bool
HQL_TLS_API_KEY	cluster.tls_api_key	String
HQL_TLS_RAFT_KEY	cluster.tls_api_cert	String
-	cluster.tls_api_danger_tls_no_verify	bool
HQL_SECRET_RAFT	cluster.secret_raft	String	x
HQL_SECRET_API	cluster.secret_api	String	x
-	cluster.health_check_delay_secs	u32
HQL_BACKUP_CRON	cluster.backup_cron	String
HQL_BACKUP_KEEP_DAYS	cluster.backup_keep_days	u16
HQL_BACKUP_KEEP_DAYS_LOCAL	s3_url.backup_keep_days_local	u16
HQL_BACKUP_RESTORE	-	String...

v0.29.4

Changes

Custom Attributes via SCIM

Rauthy's SCIM functionality now also adds custom user attributes. These will be added, just like inside the id_token claims, under custom: * as JSON values. These will be added only if the client should receive these attributes defined via the allowed scopes.

This is a non-RFC value, but it should be ignored by any client, that does not understand the custom field. While the rauthy-client has been released with a new version in the meantime, its implementation gives you access to custom attributes, if some exist.

#936

Bugfix

• It was possible, that Rauthy tried to sync groups via SCIM even if group syncing has been disabled.
  #936
• The legacy Rauthy logo showed up at the login page in versions 0.29.0 - 0.29.3 for fresh Hiqlite deployments. This was due to a missing, permanent database migration that removes the old logo. This was shadowed by the manual version migration queries that existed during the 0.28 release. This patch version has a programmatic query and will add a permanent migration with the 0.30 release to not introduce breaking changes with a patch level.
  #943

v0.29.3

Bugfix

• v0.29.2s fix for the HTTP 302 instead of 200 on /logout broke the logout from the UI without additional id_token_hint.
  #930
• Form validation for Upstream Auth Provider config did not set some fields to required under certain conditions and would therefore return the backend validation error instead of a nicer way of handling it.
  #931
• Fixed another DB migration query between Hiqlite and Postgres.
  #932

v0.29.2

Bugfix

• DB Migrations between Hiqlite and Postgres have not been working as expected since database driver and query reworks with v0.29.
  #919
• Front-Channel Logout returned HTTP 200 instead of 302 for auto-redirect under certain conditions.
  #920

v0.29.1

Bugfix

• Because of the default admin renaming with 0.29.0, the 2 test admin accounts have not been deleted when starting up a new production instance.
  #909
• Error logs with an invalid rauthy.cfg have been emitted as tracing logs instead of eprintln, when logging was not initialized yet.
  #910
• Because of the new session validation rework and additional safety-nets, a login was impossible when SESSION_VALIDATE_IP=false
  #911

v0.29.0

Breaking

Postgres: sqlx dropped in favor of tokio-postgres

Internally, quite a big change has happened. sqlx has been completely dropped in favor of tokio-postgres in combination with some other dependencies. This solved a few issues.

sqlx has been blocking updates quite a few times in the past. It pulls in a huge amount of dependencies, even if they are not used, which often block other crates. It's also pretty slow with updates, which means you might be forced to stick with older versions for several months, and it has some other limitations I don't like.

Even though the compile-time checked queries are the best feature of sqlx, they also produced a lot of issues and confusion when other people were trying to build from source, and so on.

The bonus for everyone not working with the code directly is, that tokio-postgres has about half the latency of sqlx in my testing.

The breaking change that comes with this internal change is actually a good one:

You don't specify the DATABASE_URL like before. DATABASE_URL and DATABASE_MAX_CONN have been completely removed. Instead, you now have separate config vars for each part of the URL. This removes the limitation that you could only have alphanumeric characters inside your password (otherwise the URL would be invalid).

One additional thing is, that sqlx silently ignored TLS certificate validation if it failed, which is actually a pretty bad behavior. If you are running a Postgres with self-signed certificates, you need to explicitly allow this.

You now need to provide the following values, if you are using Postgres:

# If you set `HIQLITE=false` and want to use Postgres as your database,
# you need to set the following variables:
PG_HOST=
# default: 5432
#PG_PORT=5432
PG_USER=
PG_PASSWORD=
# default: rauthy
#PG_DB_NAME=rauthy

# If your database uses a self-signed certificate, which cannot
# be verified, you might want to set this to `true`.
# default: false
#PG_TLS_NO_VERIFY=false

# Max DB connections for the Postgres pool.
# default: 20
#PG_MAX_CONN=20

CAUTION: This is a pretty big change, because existing sqlx migrations will be converted manually. Just to be safe, you should probably do a database backup before starting v0.29!

#822

Default Admin change

The default admin has been changed from admin@localhost.de to just admin@localhost. This is due to the fact that localhost.de is a real domain with a valid TLD and it could introduce issues, if these users exist on a Rauthy instance.

If you still had an admin@localhost.de around in your database, this will also be changed even for an existing deployment! You will see a warn! logging during the whole v0.29 release to make you aware of this. After the new version has been started up, your default admin will be admin@localhost.

#866

Additional PoW requirements

If you have been providing your own, custom login UI, be aware of the fact that the LoginRequest + ProviderLoginRequest now require a solved PoW inside the request body. For further information about this, see the notes down below -> Defense in depth;

#883

Internal Metrics now opt-in

The internal /metrics HTTP server is not used by most people, but it has been enabled by default, while using ~10mb of memory in idle and adding the overhead to each API request that metrics are actually collected internally. For this reason, the internal metrics (and therefore also internal Swagger UI) are not opt-in instead of opt-out. If you are using prometheus metrics right now, make sure that you explicitly set

METRICS_ENABLE=true

#876

Removed Custom CA from Auth Providers

The custom root CA option has been removed from Upstream Auth Providers. This was due to performance and efficiency optimizations. There is a new global HTTP client (mentioned below) which will handle custom root CAs and will be used for auth providers as well.

If you are currently using an upstream auth provider with a custom root CA, make sure to add this CA to HTTP_CUST_ROOT_CA_BUNDLE as mentioned further down below`

Changes

OpenID Connect Backchannel Logout

Rauthy now supports OpenID Connect Backchannel Logout.

If downstream clients support it, you can now provide a backchannel_logout_uri in the config view via the Admin UI. Rauthy itself can act as a downstream client for an upstream as well. The default /auth/v1/oidc/logout endpoint now optionally accepts the logout_token and will propagate Backchannel Logouts, if the token is actually coming from a valid, configured upstream auth provider.
Backchannel Logouts will of course also be triggered in other situations like forced session invalidation by an admin, user expiration, or deletion, and so on.

The feature can be seen as in beta state now. Everything has been implemented following the RFC and basic integration tests exist. However, to catch some weird edge cases, it needs testing in the real world as well. If you have any problems using it, please open an issue about it.

There are some new config variables:

#####################################
######## BACKCHANNEL LOGOUT #########
#####################################

# The maximum amount of retries made for a failed backchannel logout.
# Failed backchannel logouts will be retried every 60 - 90 seconds
# from all cluster nodes. The timeout between retries is randomized
# to avoid overloading clients. It will be executed on each cluster
# member to increase the chance of a successful logout in case of
# network segmentations.
# default: 100
#BACKCHANNEL_LOGOUT_RETRY_COUNT=100

# Can be set to `true` to allow plain HTTP backchannel
# logout requests.
# default: false
#BACKCHANNEL_DANGER_ALLOW_HTTP=false

# Can be set to `true` to allow insecure HTTPS logout requests.
# This will disable TLS certificate validation.
# default: false
#BACKCHANNEL_DANGER_ALLOW_INSECURE=false

# The lifetime / validity for Logout Tokens in seconds.
# These Logout Tokens are being generated during OIDC
# Backchannel Logout requests to configured clients.
# The token lifetime should be as short as possible and
# at most 120 seconds.
# default: 30
#LOGOUT_TOKEN_LIFETIME=30

# You can allow a clock skew during the validation of
# Logout Tokens, when Rauthy is being used as a client
# for an upstream auth provider that uses backchannel
# logout.
#
# The allowed skew will be in seconds and a value of
# e.g. 5 would mean, that 5 seconds are added to the
# `iat` and `exp` claim validations and expand the range.
#
# default: 5
#LOGOUT_TOKEN_ALLOW_CLOCK_SKEW=5

# The maximum allowed lifetime for Logout Tokens.
# This value is a security check for upstream auth
# providers. If Rauthy receives a Logout Token, it will
# check and validate, that the difference between `iat`
# and `exp` is not greater than LOGOUT_TOKEN_ALLOWED_LIFETIME.
# This means Rauthy will reject Logout Tokens from clients
# with a way too long validity and therefore poor
# implementations. The RFC states that tokens should
# be valid for at most 120 seconds.
# default: 120
#LOGOUT_TOKEN_ALLOWED_LIFETIME=120

#794
#819

RP Initiated Logout

While implementing OpenID Connect Backchannel Logout, support for RP Initiated Logout has been added as well to provide a complete package.

#794
#806

SCIM

This version brings SCIM support to Rauthy.

You can define a custom SCIM base uri per client. The client must support SCIM v2 and the filter parameter. Groups syncing is optional.

You can also define a group prefix which will act as a filter for the to-be-synced data. For instance, if you define a prefix of myapp:, only the groups starting with it will be synced, like e.g. myapp:admin, myapp:user. Additionally, only users that are assigned to at least one of these filtered groups will by synced, while others are skipped.
The advantage of this is, let's say you have an application with limited seats, or where each existing user costs a license (Gitlab Enterprise would be an example), you need to pay for each registered user. If you now split your users into groups and only your developers need to exist on that instance, you can assign a group like dev:* and only sync the dev: groups via SCIM.

The SCIM impl is not integration tested, as this usually requires an external deployment. For the future, the idea is to implement the client side into the rauthy-client and use this for integration testing against itself. However, I followed the RFC closely and tested all operations manually against https://scim.dev .

Just as for the OIDC Backchannel Logout, this feature can be seen as in beta state now. We need some real world testing next, but I think it should be just fine.

#####################################
############### SCIM ################
#####################################

# If set to `true`, already possibly synced groups / users on a
# SCIM server may be deleted if either sync if disabled further
# down the road.
# Depending on your clients specifically, deleting a group / user
# can have a major impact, like e.g. maybe the user had important
# data inside that application that would be deleted automatically
# as well. Depending on your use case, you may want to handle
# deletions manually.
#
# If set to false, only the `exter...

v0.28.3

Bugfix

• The new Admin UI has always added an expires value during the creation of a new user, even if the checkbox was unchecked.
  #797
• It has been possible to construct a situation in which a housekeeping scheduler for expired magic links could have been deleting newly registered users.
  #798
  #799

v0.28.2

Important

This is a pretty important bugfix update. The 0.28 versions before had an error where the groups config component in the Admin UI has been changed to contain roles after the first render. This means, if you have saved a user in the Admin UI (even without changing groups), the groups might have been changed depending on your setup.

The backend sanitizes any submitted roles / groups on user updates, so only actually existing values can exist, but if you had a roles / groups combination with the exact same naming, like e.g. an admin role and an admin group, it could have been possible that a user ends up with a group assignment he should not have. At the same time, a user might have had some groups removed he had before.

This situation can only occur on users you have updated via the Admin UI with either 0.28.0 or 0.28.1. You should update to 0.28.2 asap and double check group assignments for your users you may have updated with an earlier 0.28 version via the Admin UI.

Bugfix

• Fixes a bug in the Admin UI / Users view where the content of the groups config component contained roles instead of groups.
  #790