[
https://issues.apache.org/jira/browse/JAMES-4158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18050015#comment-18050015
]
Jean Helou commented on JAMES-4158:
-----------------------------------
Hello benoit
This sounds reasonable to me.
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.
The response of the webmin api returns the token which can then be used for
migration or admin purpose and is invalidated without further action being
required
> 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)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
