Proxy micro-services behind proper authentication flow (#352) · Issues · gargantext / haskell-gargantext

Proxy micro-services behind proper authentication flow

This ticket stems from a conversation me and @anoe had during the Paris workshop last April.

Currently, services like the frames are integrated into Gargantext by following roughly this schema: For each new frame, we generate a unique hash from its NodeId and the current secret key -- that becomes the unique hash we use in the browser to make a frame accessible to the internet.

While this is fine from a security standpoint (because the hash is unique enough to not be reverse engineer-able or brute-forceable by users by "guessing it", in other words, it's properly obfuscated) it has a few shortcomings:

It's not consistent with that we do generally in gargantext; now that we have the ShareURL feature, we potentially don't even need to generate such hash;
It relies on the secret key of the whole system; if it were ever to be compromised and we would need to rotate it, it's unclear to me the implication of this with the hashes -- they would surely change, and it potentially mean we cannot retroactively compute the old hashes unless we store the list of all the rotated keys over time;
It doesn't leverage the classic Authentication mechanism we have in the Gargantext server, and as such we cannot rely on things like the policy checking we have implemented a while ago (such that we can restrict access based on policies like belonging to a team etc).

With Alexandre we briefly brainstormed about how a "fix" would be, and one possibly way is certainly to move away from what we are doing now and stop making the frame services accessible via a direct URI, but rather have requests being proxied via the gargantext server, so that a proper Authentication flow could be bolted on.

@anoe Before we deep dive into more complex solutions, let's take a step back on the whole issue, for my own understanding: what is the real reason we generate this hash in the first place? Was this done just for easy of sharing this frame with other people?

If the answer is yes, then I think the proper solution would be to completely remove this hashing mechanism, treat this as just another "node type" and then use the ShareURL feature (or something similar) but crucially everything would be managed within Gargantext. If we can go down this route it would be best, so that we don't have to fiddle with Nginx and other things which would make the deployment more complex.

This ticket stems from a conversation me and @anoe had during the Paris workshop last April.

Currently, services like the frames are integrated into Gargantext by following roughly this schema: For each new frame, we generate a unique hash from its `NodeId` and the current secret key -- that becomes the unique hash we use in the browser to make a frame accessible to the internet.

1. It's not consistent with that we do generally in gargantext; now that we have the ShareURL feature, we potentially don't even need to generate such hash;
2. It relies on the secret key of the whole system; if it were ever to be compromised and we would need to rotate it, it's unclear to me the implication of this with the hashes -- they would surely change, and it potentially mean we cannot retroactively compute the old hashes unless we store the list of all the rotated keys over time;
3. It doesn't leverage the classic Authentication mechanism we have in the Gargantext server, and as such we cannot rely on things like the policy checking we have implemented a while ago (such that we can restrict access based on policies like belonging to a team etc).

@anoe Before we deep dive into more complex solutions, let's take a step back on the whole issue, for my own understanding: what is the real reason we generate this hash in the first place? Was this done _just_ for easy of sharing this frame with other people?