[
https://issues.apache.org/jira/browse/JAMES-4158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18050418#comment-18050418
]
Benoit Tellier commented on JAMES-4158:
---------------------------------------
EventBus has not been thought to do broadcast though it COULD be used for
broadcast by having all nodes registrating a single registration key.
(That could be a VERY good design for another feature: centralized user
disconnection, which today needs to be called node-by-node).
> 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.
> share a different perspective.
Appreciated, it is a nice discussion.
> 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]
