OIDC Directory Compatibility

[miegl]

trafficstars

Is Webadmin meant to work with OIDC directory backend?

1. The Webadmin is currently hardcoded to authenticate only with internal Oauth, with hardcoded Client ID and Redirect URI. Given the abysmal OAUTHBEARER email client support, using OIDC without Application Passwords in the self-service portal is a no go.
2. It is not even possible to use the fallback-admin account, as various APIs redirect the admin back to the login page with 401, due to Stalwart calling OIDC endpoints without a token.

[mdecimus]

It does not support external OAuth providers yet but It should work with the fallback-admin.

[miegl]

It does not. After logging in with the fallback-admin user, the webadmin calls /api/principal?types=individual&page=1&limit=10&=, which returns 401:

{
  "type": "about:blank",
  "status": 401,
  "title": "Unauthorized",
  "detail": "You have to authenticate first."
}

It looks like Stalwart is trying to verify the fallback-admin against the configured external OIDC provider (and fails). This happens with both userinfo and introspect oidc method.

Should I create a mail-server issue for this? @mdecimus

[neosonic2]

I am experiencing the same issue. I just set up my Stalwart instance to use OIDC (through my Keycloak setup) and now I am unable to log into the web admin using previously-configured (and previously-working) fallback admin credentials. No error is displayed on login. if I try to log in with an email address and password configured in OIDC so I can access the self-service portal, I get an "Incorrect username or password" error. Switching back to the internal directory from the OIDC directory causes everything to work properly again.

[mdecimus]

This will be addressed once the DAV servers are implemented.

[neosonic2]

Thanks! Is there a workaround available in the meantime for those who are using the OIDC directory?

[mdecimus]

Use LDAP if that is an option, otherwise you might try using the REST API to update the account settings.

[neosonic2]

So to clarify, until this issue is addressed, for those who don't have an LDAP setup available we'll be locked out of the web admin and need to use the REST API or CLI to make any changes to system settings? I've double checked the correct fallback admin password but still cannot access the web admin even witih the right fallback credentials.

[mdecimus]

The issue is that the webadmin requires OAuth even for the fallback admin and does not support external OAuth servers yet. So if you're using an external provider you need to use the REST API or CLI but making use you use Basic auth.

[beposec]

I think this could also handle logins for users via OIDC.

It should help creating an account and picking an email alias when not existent.

It should allow users to set an app password and encryption in the self service portal.

[lambdaupb]

I wasted a lot of time today trying to get external OIDC working.

There are no mail clients supporting the BEARER thing, so I need an application password. For that I need to login to the self-service portal and set one, but that doesn't work with external OIDC.

[smndtrl]

This will be addressed once the DAV servers are implemented.

@mdecimus Is this still the expected timeline?

[mdecimus]

@smndtrl Yes, this is going to be implemented within the next few weeks.

[mdecimus]

This has been partially implemented. It's now possible to access the Webadmin interface using the fallback admin account even when OIDC is enabled.

However, enabling users to manage their own app passwords through the Webadmin is more complex. The current Webadmin is a single-page application tightly integrated with Stalwart’s internal authentication system, as its primary purpose is administrative system configuration. Supporting third-party OIDC providers in this context would require significant changes, which isn't a direction we’re prioritizing, mainly because the existing self-service portal will eventually be replaced by a new webmail interface. That new interface will be decoupled from the internal auth system and fully compatible with any OAuth provider.

That said, it is technically possible for users to manage app passwords with the current Webadmin. To do so, they must first authenticate using an app password, which then allows them to create additional app passwords. Admittedly, this isn't ideal, but it serves as a temporary workaround for those who prefer not to use the REST API for app password management.