Something I want to note here, and will maybe create a Wiki page for, is about the security strategy suggested for storing the ExternalServerJwtMasterSecretKey in ExternalLoginKeysManager class.
The question is simple: what is the best place to store a secret key? Of course there are several answers to this question and you might prefer your own, but be sure that it's as safe as you imagine.
Here is a good summary about this question: https://security.stackexchange.com/questions/12332/where-to-store-a-key-for-encryption
Traditionnaly in OFBiz we use properties files. There is at least 2 examples OOTB: janrain.apiKey and login.secret_key_string.
So this seemed the most appropriate to me when I first thought about it. But then because here it's about getting access to another server I began to be more cautious. What happens if someone get a read access to the server and can read the content of this properties file? Then this person might get access to the other server, and the purpose of the JWT token is completly lost!
The problem with a properties file is you need to keep it on the server to be able to read it when needed, I already commented about that above.
You might be tempted to store the secret key in the Database. When it's only about a server it's IMO far from the best solution
But when, like here, the functionnality allows access to another server then if the Database on the source server is compromised this possibly grants access to the other server for an attacker. Since the funcionnality allows access from one server to another, by transitivity this potentially allows access to more than 1 target server.
For me the best simple solution is a file that you remove from the production server. Nicolas suggested, a file where the secret key is modified by sed using uuidgen on each build, and I agreed. But we missed something: the ExternalServerJwtMasterSecretKey must be the same on both servers (and etc.). So using uuidgen during build on each machine is innapropriate. Nevertheless the uuidgen solution is still interesting because it increase the difficulty for an attacker to know the ExternalServerJwtMasterSecretKey, but you could use a fixed ExternalServerJwtMasterSecretKey as well.
A solution is to generate a uuid using uuidgen somewhere safe, or use a fixed ExternalServerJwtMasterSecretKey, and copy it using sed on the production servers. Since it's preferable to have the same deployment script on each production server I suggest to generate the uuid on a devlopment machine, or use a fixed ExternalServerJwtMasterSecretKey, and pass it to the deployment script. I recommend to not use an environment variable to pass the uuid as those can be considered weak:
Several means can be used to pass the ExternalServerJwtMasterSecretKey to the deployment script, among them
- copy it from the deployment machine using a temporary connection, possibly from an USB key removed after from the deployment machine to guarantee a total confidentiallity!
- from an USB key removed after from the production servers to guarantee a total confidentiallity (harder with cloud solutions)
- manually by the OPS somehow (again avoid an environment variable)