[
https://issues.apache.org/jira/browse/JAMES-4158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18050230#comment-18050230
]
Jean Helou commented on JAMES-4158:
-----------------------------------
> > 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.
Not at all, but it does mean you need to distribute the generated tokens (and
their TTLs) to all nodes but we do have an event bus to supports this
distribution. This is how email filters are distributed in the pulsar
implementation for example (though not through the event bus since it's an
implementation detail of the pulsar mailqueue).
An in memory distributed design with builtin TTL makes it harder for an
attacker (even with VM/pod access) to get the tokens. They would have to
analyze the process memory which modern OS make more difficult. It doesn't
rely on k8s specific features to make the feature easy to use in a reasonably
secure way and it supports or allows a larger set of use cases down the road.
Typically exposing a temporary credential for helpdesk to help a user without
requiring L2 or L3 support (you) to intervene would become much easier to
implement.
I won't fight against your design any further just wanted to share a different
perspective.
> 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: 20m
> 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]
