Open chibenwa opened 6 days ago
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?
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:
If configured, XUserAuthenticationSStrategy would enforce the incoming request to have the following header:
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