[jira] [Created] (JAMES-4158) IMAP: admin impersonation on dedicated ports

Benoit Tellier created JAMES-4158:
-------------------------------------

             Summary: IMAP: admin impersonation on dedicated ports
                 Key: JAMES-4158
                 URL: https://issues.apache.org/jira/browse/JAMES-4158
             Project: James Server
          Issue Type: Improvement
          Components: IMAPServer
            Reporter: Benoit Tellier


As off today we allow configuring an administrator into usersrepository.xml

This administrator can impersonnate for both IMAP and SMTP any users.

This is very useful for:
 - Migration, as it is compatible with IMAP sync and do not require to have access to all users credentials
 - Administrators, when doing support, eg helping on folder subscriptions.

While convenient, it is nonetheless dangerous as those creds are operational on publicly exposed interface. This means that, eg an admin leaving the organisation would still retain impersonnation god-like access, and credential rotation is needed in emergency.

h3. Goal

Limit admin user impersonnation to *private* interfaces. Allow not to expose it onto public IMAP endpoints.

That way in the aforementioned exemple radiation from the VPN is enough to immediately revoke access for the ex-admin. While still very beneficial, the rotation of the credential is not to be done in an emergency fashion.

h3. What

Be able to configure in imapserver.xml, on a per port fashion the list of allowed users eg:

{code:java}
<auth>
  <adminUsers>[email protected]</adminUsers>
</auth>
{code}

h3. How?

We can use ImapConfiguration POJO to cary this information ahead as it is per imapServer specific and not global.

We would need to "overload" the main authorizator with protocol specific logic.

h3. Alternative

This implementation is hardly implemented in a separate vendor specific extension as:
 - IMAPConfiguration POJO is static and adding custom fields is not supported.
 - Ability to overload the Authorizator is still a need
Given those two blockers lifted this could be implemented in a LINAGORA specific code base.

On a personal note I believe this proposition to be very benefic to other members of the community and thus would like it to land in the James code base.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)