> On 22/08/2022 11:11 EEST Felix Auringer <felix.auringer@giz.berlin> wrote:
>
>
> Hi,
>
> I tried to configure / implement the suggestions - thanks for them @Aki!
>
> On 6/15/22 07:50, Aki Tuomi wrote:
> >
> >> On 14/06/2022 12:52 Felix Auringer <felix.auringer@giz.berlin> wrote:
> >>
> >>
> >> Hi,
> >>
> >> we're trying to set up an IMAP server using Dovecot as part of a new
> >> email system in a middle-sized company (around 150 employees). We have a
> >> keycloak identity server that is used for all logins and we would also
> >> like to use it for the new email system so that the non-technical
> >> employees (the majority) will have no issues using it.
> >>
> >> It's very nice that XOAUTH2 is already included in Dovecot, it works
> >> very well with our Roundcube web client. However, it seems that other
> >> clients like Thunderbird or Android Apps like FairEmail are not easy to
> >> set up as they have their XOAUTH providers hardcoded somewhere
> >> (https://bugzilla.mozilla.org/show_bug.cgi?id=1602166). Are you aware of
> >> any solution to integrate a dovecot server using XOAUTH2 into local
> >> clients (like Thunderbird)? We are currently trying to do it with
> >> passwords that can be set in Keycloak only for the purpose of email that
> >> can then be used to receive a valid token via a direct access grant but
> >> it's not a really nice solution as it introduces an additional password.
> >>
> >
> > Unfortunately this is a client-side restriction. You should use either
> > device passwords or you can use the "password grant mode" where dovecot
> > authenticates to keycloak with username & password.
>
> I used the password grant mode and it works fine!
>
> > Dovecot supports openid_configuration_url which should be supported
> > eventually.
>
> Sadly, the clients we intend to use do not support this yet but I will
> keep it in mind to hopefully use it later on.
>
> >> Additionally, we would like to have all permission-related information
> >> saved in our identity server. For email, this includes shared mailboxes
> >> that a user is allowed to access. The ACL plugin that is used for shared
> >> mailboxes currently reads the permissions from disk which is not really
> >> feasible if the user base is large and setting these permissions should
> >> happen automatically. We are thinking the best way to do this is to
> >> encode the user's permissions in the token that dovecot receives in the
> >> login process. But as the token is only available in the authentication
> >> process and it does not seem to be intended to return such information
> >> from the password database
> >> (https://doc.dovecot.org/configuration_manual/authentication/password_database_extra_fields/),
> >> we are unsure on how to process these information from the token. We did
> >> not find any plugin hooks in the authentication processes and the normal
> >> plugin hooks do not have access to information from the token anymore.
> >> What do you think is the best way to do this? We would be okay modifying
> >> some dovecot source code and contributing it back if desired.
> >>
> >
> > You can't really store this in your identity server. Currently the only
> > supported backing for acl information is file, so there is no mechanism for
> > passing ACL permissions via passdb, and it would not be that feasible
> > either.
>
> My plan is rather to implement a new ACL backend that does not read the
> permissions from files but instead uses the permissions encoded in the
> JWT Token.
>
> > In general, dovecot makes fields present in JWT tokens available if you use
> > local validation, you can use %{oauth2:field} to export them into mail
> > process from passdb using pass_attrs:
> >
> > pass_attrs = userdb_foo=%{oauth2:field}
>
> I setup dovecot to do local validation and this seems to work fine. The
> auth process sends the configured oauth2 fields to its client (the log shows
> `client passdb out: OK 1 user=<...>
> email=felix.auringer@giz.berlin
> token=<...>` where the email field is extracted from the JWT token).
> However, I can not really find the place in the imap-login client (if
> that is even the right place to look) where the information are
> processed. The result should be available in `sasl_callback` in
> `src/login-common/client-common-auth.c`. But as far as I understand it,
> this calls `imap_client_auth_result` which does nothing with the reply
> if the authentication was successful. I also tried to read the values
> from the user struct using my plugin but could also not find any fields
> that contain the fields from the JWT.
> Could you explain where the JWT fields are available for plugins after
> the login is finished? And / or point me to the place in the imap-login
> source where the JWT fields from the authentication reply are processed.
>
Hi!
You need to export them in passdb. You can do
`userdb_some_field=%{oauth2:some_field}`.
> >> Best regards,
> >> Felix Auringer
> >> ---
> >
> > Regards,
> > --
> > Aki
>
> Regards,
> Felix Auringer
Regards
--
Aki
