v0.32.3

Bugfix

• When deleting a client, there was a last case that could make the deletion fail under specific circumstances.
  #1198

v0.32.2

Security

Some external dependencies have been bumped because of security issues. However, these either only affected development servers, or were false-positives, because the fixed versions were being used already, just not set in the lock files.

Changes

Additional Events

For improved auditing, Rauthy now emits the additional event types LoginNewLocation and TokenIssued.

The LoginNewLocation will be emitted when ever a user does a login from a new / unknown location. The TokenIssued event will be triggered after each JWT token creation. Especially the TokenIssued can become spammy, if you have a huge amount of users. Because of this, you can disable the generation of these events. You get some new config variables:

[events]
# Can be set to `false` to disable events being generated
# when a new token was issued. These events improve your
# auditing, but they can also be considered spam if you
# have a huge amount of users and logins.
#
# default: true
# overwritten_by: EVENT_GENERATE_TOKEN_ISSUED
generate_token_issued = true

# The level for the generated Event after a login from
# a new location for a user.
#
# default: notice
# overwritten by: EVENT_LEVEL_NEW_LOGIN_LOCATION
level_new_login_location = 'notice'

# The level for the generated Event after a new JWT
# Token was issued.
#
# default: info
# overwritten by: EVENT_LEVEL_TOKEN_ISSUED
level_token_issued = 'info'

#1192

Translations for Norwegian Bokmål

Rauthy now has Norwegian Bokmål (nb) for Admin and User UI translations.

#1180

Bugfix

• It was possible to get into a race condition during client deletion under some conditions.
  #1190
• API Keys were missing a PAM access rights group.
  #1191

v0.32.1

Security

• Make sure a page_size of 0 will not be accepted when doing server-side searches for users or sessions to prevent a possible division by 0. This did not lead to a panic because of a conversion into f64, but definitely to an unexpected answer to the client from the calculation for the next page. The max value for it is now also limited and instead of u16::MAX, the max is server.ssp_threshold.
  #1165
• Make the secret comparison for OIDC clients and PAM hosts constant time.
  #1167
• Fix logic bug in SVG sanitization for user pictures and allow direct SVG upload via the Account Dashboard. Also add a specially hardened CSP to the client and user picture endpoints.
  #1168
  #1169
• Remove a reachable unwrap() in the Cache GET handler, which was possible if a request is being cancelled before awaiting the answer from the cache. This was fixed in hiqlite-0.10.1 as a dependency.
  #1177

Changes

User Name validation

' is now an allowed character in user user.given_name and user.family_name.

#1171

Self-Signed TLS certificates

As part of the repo cleanup before an upcoming v1.0.0, the static DEV TLS certificates were removed from the repo. Rauthy can now generate self-signed certificates (with a proper CA for more in-depth testing) on its own. A CA with a lifetime of 10 years will be generated and saved (encrypted) into the database. This CA will be used to create self-signed TLS certificates for the HTTPS server, and all nodes of an HA cluster will make use of it.

[tls]
# If set to `true`, Rauthy will generate self-signed TLS certs and copy
# them into `tls/self_signed_cert.pem` and `tls/self_signed_key.pem`.
# It will also IGNORE any `cert_path` / `key_path`.
#
# CAUTION: If set to `true`, it will delete existing files:
# - `tls/self_signed_cert.pem`
# - `tls/self_signed_key.pem`
#
# This should only be used for testing and never in production!
#
# default: false
# overwritten by: TLS_GENERATE_SELF_SIGNED
generate_self_signed = true

#1173
#1174

v0.32.0

Changes

PAM + NSS Modules

OIDC / OAuth covers almost all web apps, and for those that don't have any support, Rauthy comes with forward_auth support. To not need an additional LDAP / AD / something similar for your backend and workstations, Rauthy now has its own custom PAM module. It does not just use JWT Tokens for logging in, but you can actually manage all your Linux hosts, groups and users in different ways. You have the option to secure local logins to workstations via Yubikey (only USB Passkeys supported, no QR-code / software keys), and all SSH logins can be done with ephemeral, auto-expiring passwords, that you can generate via your Account dashboard, if an Admin has created a PAM user for you. This means you get MFA-secured SSH logins without the need for any modifications or additional software on your local SSH client, and you can use any SSH client from any machine securely, even if it's not your own.

In addition to the PAM module, you there is an NSS module and an NSS proxy that run on each machine. You can dynamically log in to any machine an Admin has given you access to. Users and groups are not added to local files, but will be resolved via the network.

This module is published in a separate repo to avoid licensing issues, since it relies on some GPLv3 dependencies. You can take a look at it here: rauthy-pam-nss. It has been tested with local terminal and window manager logins, as well es via SSH, but it should work basically anywhere where you can authenticate via PAM.

A more detailed documentation was added to The Book already.

[pam]
# The length of newly generated PAM remote passwords via the
# account dashboard. The default is fine as long as you can copy
# & paste them. You may want to reduce the length here if you e.g.
# occasionally generate them on mobile and need to type them
# manually into some terminal.
#
# default: 24
# overwritten by: PAM_REMOTE_PASSWORD_LEN
remote_password_len = 24

# The TTL for newly generated PAM remote passwords in seconds.
# The default gives you plenty of time to open a few sessions in
# some terminals and maybe switch to `root` on some remote machines,
# while still expiring quick enough to be secure.
#
# default: 120
# overwritten by: PAM_REMOTE_PASSWORD_TTL
remote_password_ttl = 120

Even though a lot of testing was done, I am pretty sure there are still some issues or maybe SELinux warnings that need to be fixed, but it should be absolutely usable. Everything is secured, but it may still lack a good UX here and there.

#1101
#1132
#1134
#1142

SMTP: XOAUTH2 + Microsoft Graph

Because Microsoft does really stupid things, and they disable SMTP basic auth in september, you can now also connect via SMTP XOAUTH2, or if even that is an issue for you, you can use the Microsoft 365 native Graph API. Both options require you to provide all necessary values to fetch an OAuth token via client_credentials flow and the SMTP connection may be re-opened when the token expires.

Both of these options are worse than the default. Against all misleading blog posts about it, they provide absolutely no advantages in security, and you should not use them, if you can stick with the default. Both options have an overhead of fetching, storing and refreshing the token, and re-opening the connections over and over. Especially the Graph API is pretty slow and it should be your last resort.

There are some new config options available in the email section:

[email]
# You usually do not need to change this value. The 'default'
# will connect via SMTP PLAIN or LOGIN, which works in almost
# all scenarios. However, you can change it to `xoauth2` to
# connect via XOAUTH2. In addition, there is also `microsoft_graph`.
# It is a custom implementaion that does not use SMTP anymore,
# but instead the Microsoft Azure Graph API. You should not use
# it, unless you have no other choice or a very good reason.
#
# If you specify another value than ´default`, you must provide
# all the additional `x_oauth_*` values bwloe.
#
# possible values: 'default', 'xoauth2', 'microsoft_graph'
# default: 'default'
# overwritten by: SMTP_CONN_MODE
smtp_conn_mode = 'default'

# These values must be given if `auth_xoauth2 = true`.
# They will be used for a `client_credentials` request
# to the `xoauth_url` to retrieve a token, that then
# will be used for authentication via SMTP XOAUTH2.
#
# overwritten by: SMTP_XOAUTH2_URL
xoauth_url = ''
# overwritten by: SMTP_XOAUTH2_CLIENT_ID
xoauth_client_id = ''
# overwritten by: SMTP_XOAUTH2_CLIENT_SECRET
xoauth_client_secret = ''
# overwritten by: SMTP_XOAUTH2_SCOPE
xoauth_scope = ''

# Only needed if `smtp_conn_mode = 'microsoft_graph'`:
# https://learn.microsoft.com/en-us/graph/api/user-sendmail?view=graph-rest-1.0&tabs=http
#
# default: not set
# overwritten by: SMTP_MICROSOFT_GRAPH_URI
microsoft_graph_uri = ''

#1136

Auth Providers Onboarding + Link

Upstream Auth Providers have 2 new options:

• auto-onboarding
• auto-link user

The auto-onboarding should be self-explanatory. If a user does not exist yet inside Rauthys DB after a successful auth provider login, it will automatically be created. This was the default up until now. However, this allows anyone with an account on the upstream provider to log in, and even though such a user would not have any access rights, this may be unwanted. To "fix" this, you can now decide to disable auto-onboarding.

To still provide a good UX for new users, the additional auto-link user option will allow an Admin to create an fresh account, that has no password or anything else set. A user can decide to not create a password for Rauthy, but log in via the upstream provider directly and if this option is set and the user is not linked to any other provider yet, it will auto-link this user to the upstream provider on login.

CAUTION: This option will show you a warning in the Admin UI as well. If you set auto-link user and your upstream provider does NOT VALIDATE E-Mail addresses 100% correctly, and allows a user to set an address that belongs to someone else, this option can lead to account takeover! Do NOT use it if you cannot fully trust the validation process of the upstream provider!

#1153

EncKeyID Validation

The validation regex for EncKeyIDs has been relaxed a tiny bit. It was changed from ^[a-zA-Z0-9]{2,20}$ to ^[a-zA-Z0-9:_-]{2,20}$.

Bugfix

• The default value for rp_origin during LOCAL_TEST=true was set to a value that would not work out of the box.
  #1138
• Overwriting ENV vars would not be parsed, if the underlying section did not exist at all in the config file. This was not an issue on its own, because there was nothing to "overwrite" in the first place, but probably unexpected behavior.
  #1147
• If a given redirect_uri for a client already contained query params, the final URI was not built correctly.
  #1148
• session.validate_ip was not respected during /forward_auth.
  #1149

v0.31.3

Bugfix

• The key creation of RSA keys for the RS256 signing algorithm had a typo and generated 2028 bit keys instead of 2048. This tiny difference is not really a huge issue in terms of security, but it made some clients fail to validate the tokens, because they expected 2048.
  That bug came in with the big JWT rework in v0.30 and the Custom JWT implementation. If you currently have issues with some client that uses RS256, you will get a new pair of keys via: Admin UI -> Config -> JWKS -> Rotate Keys
  #1124
• The automatic Session Refresh action on the Login UI stopped working under some conditions. By default, as long as you have a valid session (and other config + request variables are met), you should not be prompted for another login and the UI should refresh your session automatically and log you in. The effect trigger logic in the UI was reworked slightly, and it fixed the issue in my test setup. If someone still has problems, please open an issue about it.
  #1128

v0.31.2

Bugfix

• It was possible that a "Login from new location" notification was sent out for Passkey-only accounts, if someone knew all the right values incl the username, but was not able to get past the MFA / Passkey challenge. This would have been a false-positive.
  #1105
• After Rauthy received an accessibility review from HAN as part of the NGI funding, it was declared as "fairly accessible" already, but there were still some things that have been improved after the review.
  #1099
• When using the MIGRATE_DB_FROM feature, some of the latest changes and features were missing in migration queries.
  #1116

v0.31.1

Bugfix

• The Login Location check during the code flow has been done on POST /token instead of /authorize and it therefore caught the OIDC client app instead of the user browser.
  #1097

v0.31.0

Breaking

Empty User-Agents rejected

While implementing Geoblocking (see below), a check for the User-Agent has been added. If this is empty, requests will be rejected. If you are doing something via API-Keys, make sure your clients send a proper User-Agent header. This rejection does not provide any security at all, it just catches a few bots out of the box.

Changes

Remembered Login Locations

Rauthy will now remember Login locations / IPs for each user and send out an E-Mail notification, if a login from a new IP / location was done. This E-Mail will also contain a link to revoke all Sessions and Refresh tokens for this user, which will also trigger a backchannel logout to all configured clients, in case an invalid login was done for a user. Users should be able to handle these situations without the need of an Admin in this case.

#1072

IP-Geoblocking

Rauthy can now block requests depending on the origin country of the peer IP address. You can either provide a custom header value, which is inserted for instance by a WAF or CDN, like in case of Cloudflare the CF-IPCountry header, or you can opt-in and provide a Maxmind AccountID + License for either the free GeoLite databases, or a paid version of it. These GeoLite databases are published under the Creative Commons License, you only need to create a free account to generate a License. Rauthy will download the configured DB and update it regularly.

This IpGeo information will also be used for the Remembered Login Locations feature above. The country and depending on the chosen DB type also the city will be added to the E-Mail notice.

[geolocation]
# If you have a configured and working Geolocation setup, you can
# define if un-resolvable IP addresses should be blocked. By default,
# if a Country cannot be found for a certain IP address, it will be
# allowed anyway. This is necessary to allow private network connections
# for instance. Only if you run a public Rauthy instance, and you will
# guaranteed always connect with a public Peer IP, you might want to
# set this to `true`.
#
# default: false
# overwritten by: GEO_BLOCK_UNKONW
block_unknown = false

# If you have a WAF or CDN which injects a geoloaction header
# with the country code, provide the name here. For instance,
# in case of Cloudflare, this would be 'CF-IPCountry'.
#
# This header will only be accepted, if Rauthy runs in proxy_mode,
# and the source IP is a trusted proxy, to prevent spoofing.
#
# default: not set
# overwritten by: GEO_COUNTRY_HEADER
country_header = 'CF-IPCountry'

# You can black- or whitelist countries, if you have a configured
# and working Geolocation, either via `country_header` or a
# Maxmind database.
#
# The `country_list_type` can be either `whitelist` or `blacklist`,
# and it will specify the behavior of the `country_list`.
# For instance, if you have `country_list_type = 'whitelist'` and
# `country_list = ['DE', 'FR']`, only access from Germany and France
# will be allowed.
#
# The `whitelist` type is a `default-deny`, while `blacklist` is
# `default-allow`.
#
# If `country_list_type` is not set at all, Geoblocking will be
# disabled.
#
# default: not set
country_list_type = 'whitelist'
# default: not set
country_list = []

# If you don't have a header with a country code, you can
# also provide a Maxmind account. Rauthy will then download
# the 'GeoLite2 Country' database regularly and use it for
# geolocating IPs.
#
# The GeoLite databases from Maxmind are free and published
# under the Creative Commons License. You can also provide
# an Enterprise database, which will have more accurate data.
# Check the `maxmind_db_type` below.
#
# default: not set
# overwritten by: GEO_MAXMIND_ACC_ID
maxmind_account_id = ''
# overwritten by: GEO_MAXMIND_LICENSE
maxmind_license_key = ''

# If `maxmind_account_id` and `maxmind_license_key`, this
# will be the directory being used for DB download and storage.
#
# default: 'data'
# overwritten by: GEO_MAXMIND_DIR
maxmind_db_dir = 'data'

# By default, the `GeoLite2-Country` database from Maxmind is
# being used. The IP Geolocation databases are loaded fully into
# memory at startup to speedup lookups. The size therefore makes
# a big difference, not only for lookup speed, but also in terms
# of memory usage. The Country DB adds ~10MB of memory overhead,
# while the City DB is around 65MB.
#
# Possible Values (case-sensitive):
# - GeoLite2-Country
# - GeoLite2-City
#
# If you have access to paid Maxmind databases, you can add the
# db_type in a way that it resolves to a valid download link.
# The link will be created with the following template:
# `https://download.maxmind.com/geoip/databases/{maxmind_db_type}/download?suffix=tar.gz`
#
# default: 'GeoLite2-Country'
# overwritten by: GEO_MAXMIND_DB_TYPE
maxmind_db_type = 'GeoLite2-Country'

# If you configured a `maxmind_account_id` + `maxmind_license_key`,
# you can change the time when the DB update job runs. By default,
# it runs every night at 05:00. It will check if y new version of
# the MaxMind DB is available and if so, download it.
#
# Accepts cron syntax:
# "sec min hour day_of_month month day_of_week year"
#
# default: "0 0 5 * * * *"
# overwritten by: GEO_MAXMIND_UPDATE_CRON
maxmind_update_cron = "0 0 5 * * * *"

While IP Geo data is very helpful and can boost your security, it is fully optional. Everything will work if you don't provide any of the > options. You just won't have Geo data in the "Login from new location" notifications and other places, and you will of course not be > able to block requests depending on the origin country.

#1077

TLS Hot-Reload

Rauthy can now hot-reload TLS Key + Certificates. If started with server.scheme set to any https value and TLS certificates are used, Rauthy will watch for file changes on tls.cert_path + tls.key_path and will do a hot-reload of the TLS configuration if anything changes. This is a real hot-reload, meaning there is no restarting the server, and it does it without any interruption in service.

#1056

OIDC-backed Forward-Auth

In addition to the already existing, very simple /forward_auth endpoint, which has limited compatibility, Rauthy now provides a very much advanced version of it. This new version is not a replacement of the old approach, but an addition.

The already existing endpoint is very simple: It expects a valid JWT token to be present in the Authorization header, parses and validates it, and if it's valid, it returns an HTTP 200 and a 401 otherwise. Depending on auth_headers.enable, it will also append the Forward-Auth headers to the request, which the reverse proxy could inject into the request sent to the downstream client.

The new version is much improved. It does not work with stateless JWT tokens, but it binds to the Rauthy session. This makes it possible to revoke access as any time. It can also do proper CSRF checks, validates the client and user configuration, and it can make everything work without any modification to the client. On auth success, it behaves in the same way as the already existing endpoint. On invalid though, it will redirect to Rauthys Login, which then again will do another redirect to a Callback UI and therefore trigger a complete OIDC flow. On the callback page, Rauthy can now set fully-secured session cookies and do others things like check the Sec-Fetch-Site header. This is the most secure it can get, without modifications to the client. The callback page is exposed by Rauthy itself, and can be "injected" into the client app at your reverse proxy level, which makes all of this as secure as possible.

You can do this new Forward-Auth for any client, as long as it's configured properly. Rauthy is quite a bit more strict about the correct client config upfront. This makes it possible to have a few additional safety hooks which will help you prevent unwanted, invalid reverse proxy config, which can happen very quickly for complex setups.

CAUTION: Even though this is probably the most secure you can get with Forward-Auth, it should still only be the last resort, and you should always prefer a native OIDC client implementation, if it exists! If you screw up the reverse proxy config, or if an attacker can find a way around your reverse proxy and skip it, all your security will be gone immediately.

The Rauthy book will be updated in the upcoming days and provide a bit more documentation about the setup.

To help during Forward-Auth setup and making sure you got it right in your environment, the /auth/v1/whoami endpoint has received an update as well. You can now set access.whoami_headers = true or use WHOAMI_HEADERS. This will make the /whoami endpoint not only return the extracted "real IP", but it will also return all request headers it received. This will help you make sure your setup is working correctly, if you use auth_headers. By default, this is set to false. Depending on your internal network setup, this could expose sensitive headers, if you inject any. It will not return values for Cookie and Rauthys own CSRF token headers, but all others return will show their raw values.

#1053

Backups via Admin UI

If Rauthy is running with Hiqlite as the database, you can now view and download existing backups via the Admin UI -> Config -> Backups section. It shows local backup files and the ones on S3 storage, if it's configured. You also get the option to trigger manual backups with a new button, which gets rid of the issue of updating the cron task to "a few minutes in the future" to trigger a backup on demand.

If you run a HA cluster and want to d...

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!.