Hi there,
i am trying to find a way to encrypt UserEntity columns for keycloak. There seem to be different approaches worth investigating, i am looking for your help to navigate this minefield.
Requirements
- only needs to work with postgres + pgcrypto (pgp_sym_encrypt / pgp_sym_decrypt)
Approaches
1.) patch queries in keycloak source
This needs a very diligent process to find all UserEntity-related queries. Such patches would most likely blow up in your face after a few keycloak updates.
2.) use @ColumnTransformer annotation
Should work if transformers are used by all EntityManager-generated queries. From my p.o.v. this would require only adapting the named queries inside the UserEntity.java file.
3.) application side encryption and decryption
While it would be feasible to replace the getters and setters of the UserEntity with encrypting/decoding getters and setters, this solution requires to patch all WHERE clauses using encrypted columns to use pgp_sym_decrypt. This suffers the same problems as approach 1).
My current conclusion
The only approach that provides some hope seems to be 2.) @ColumnTransformer . The other ones are either to deeply integrated and hard to maintain or breaking functionality like lookups.
Questions to you
As the last time i had to use Java is roughly 20 years ago, please be patient with me. I have no clue regarding JPA and such. So could you please point out misconceptions of mine? And could you please confirm things that sound correct?
a) Is @ColumnTransformer annotation sufficient to automagically change all EntityManager SQL queries? Is there code inside keycloak sources that somehow bypasses EntityManager?
b) Do i need to search for more queries related to UserEntity outside of UserEntity.java which use hardcoded SQL like the named queries?
c) Annotations will only accept constant strings, so in order to not expose the keys in the annotations, there needs to be a runtime update to the annotation values from environment / secrets vault / secrets file. This should be feasible.
d) While my requirements seems to make this a manageable approach, this would be a solution which would have to be kept separate from the DB-agnostic keycloak code base.
Thank you very much for your input!