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

     [ https://issues.apache.org/jira/browse/JAMES-4158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benoit Tellier closed JAMES-4158.
---------------------------------
    Resolution: Fixed

> 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
>            Priority: Major
>          Time Spent: 1h
>  Remaining Estimate: 0h
>
> 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)