OIDC Directory: Domain-less groups handling

Issues
1

Issue Description

I’ve configured an OIDC directory with claimGroups set. My OIDC provider returns groups without a domain part, e.g. staff not staff@domain. These groups get the default domain appended.

It is, arguably, more expected/useful to append the configured usernameDomain.

This is not a major or blocking issue for me, but figured I’d report it when I found it due to finding it unexpected. (Ideally though, this is worked around by making sure that the OIDC IdP returns fully qualified group claim values. But FYI for users of Kanidm: it currently has a limitation with very strict character set for claim values not allowing for email-like values.)

Expected Behavior

Domain-less groups from claim value get the usernameDomain appended, just like bare usernames from the directory. (Or there’s a separate groupDomain setting created to allow specifying it.)

Actual Behavior

Domain-less groups get the system’s default domain appended.

Reproduction Steps

  1. Set up OIDC directory with groups claim
  2. Log in through OIDC with account with bare group claim values
  3. Observe groups created with default domain

Stalwart Version

v0.16.x

Installation Method

Docker

Database Backend

RocksDB

Blob Storage

RocksDB

Search Engine

Internal

Directory Backend

OIDC

I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.

on

I have searched this support forum (open and closed topics) and confirm this is not a duplicate.

on

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

Let me look at the OIDC directory source code to understand how groups and domains are currently handled.

The behavior you’ve identified is confirmed by the source code. Here’s what’s happening:

In build_account, the groups claim values are extracted via extract_string_list and stored as-is – there is no domain-appending logic applied to group names at all. In resolve_email (which handles usernames), there is logic to append default_domain when no @ is present. So group claim values bypass the usernameDomain/default_domain logic entirely and are stored verbatim.

When those bare group names (e.g. staff) are later used, Stalwart will fall back to appending the system’s default domain, which is the unexpected behavior you observed.

To summarize the confirmed behavior:

  • Bare usernames from the username claim: default_domain (usernameDomain) is appended if no @ is present. :white_check_mark:
  • Bare group names from the groups claim: no domain is appended at all by the OIDC backend – they are stored as plain strings, and whatever domain-fallback happens later uses the system default rather than the configured usernameDomain. This is a code-level gap, not a configuration issue.

Workaround: As you noted, configuring Kanidm (or your OIDC provider) to return fully-qualified group values like [email protected] in the groups claim would sidestep this entirely. Unfortunately Kanidm’s current character-set restrictions on claim values make this difficult in practice.

There is no existing groupDomain configuration knob – that would require a code change to implement.

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.