Safer X-User

[chibenwa]

Why?

As of today, James relies on Apisix for OIDC enforcement and propagates the calls to james, identifying the user through the mean of X-User header.

This means that any access to the JMAP port onto James means full compromission (integrity and confidentiallity) of the underlying data.

While of course an attacker shall not breach onto a private network, having a seat-belt for this definitly can save the day!

Having a shared secret to prove identity of the caller could achieve this (caller would need either man-in-the-middle / compromise either APisix or James which would anyway in itself compromise the email data).

Such a shared secret would greatly reduce the attack surface...

How?

Have a configurable shared secret for X-User in jmap.properties:

authentication.strategy.rfc8621.xUser.secret=abcdefghijkl

If configured, XUserAuthenticationSStrategy would enforce the incoming request to have the following header:

X-User-Secret: abcdefghijkl

And reject non compliant request with 401

We would need to modify our Apisix plugin to add the shared secret optionnally there too.

If omitted all requests are accepted (today behaviour)

Dod

• James code modified
• Apisix code plugin modified
• imap.linagora.com updated
• CNB updated
• Twake workplace updated
• MU updated

[chibenwa]

Safer version: have the secret being a JWT with as a scope the user and an expiration.

James would only need public key. Apisix shall hold the privateKey.

Costs is a bit higher as James shall verify the signature.

We could keep that as a possible enhancement?

[quantranhong1999]

I propose a new XUserWithSecretAuthenticationStrategy to avoid breaking changes.

[chibenwa]

I propose a new XUserWithSecretAuthenticationStrategy to avoid breaking changes.

+1 good idea.

And @deprecate the older one...

[chibenwa]

(Moved in Todo as I really want this....)