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

    [ https://issues.apache.org/jira/browse/JAMES-4158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18050025#comment-18050025 ] 

Benoit Tellier commented on JAMES-4158:
---------------------------------------

Hello Jean

> Out of curiosity would a temporary admin credential held in memory work ?
> Something which would be created through webmin for instance possibly with a TTL provided in the request. 

This could potentially be implemented as an evolution / extension to the proposed mechanism.

> held in memory

Well this makes it non distributed friendly: you need to speak to the exact node queried. At LINAGORA we generally speak to k8s ingress instead.

Now in terms of security guaranties the benefit to me seems slim: if I have internal access (webadmin, network) I can still self generate secrets. I fail at gasping what benefits we would get with this compared eg to a CRON rotating the secret for instance every 1 day... (easy to do with K8s secrets...)

> 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: 10m
>  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)