[
https://issues.apache.org/jira/browse/JAMES-4158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18050427#comment-18050427
]
Jean Helou commented on JAMES-4158:
-----------------------------------
>> They would have to analyze the process memory which modern OS make more
>> difficult.
> Or they could also generate the token themselves byeg reading the webadmin
> config.
true they could generate their own tokens (possibly using the JWT key from the
webadmin config if one is defined)
> 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: 0.5h
> 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]
