Kafka+SQL "created-by" property needs to be populated once the Auth branch is merged

Once we have the auth branch merged into master we should make sure that the Kafka+SQL implementation properly sets the createdBy field. References are:

https://github.com/Apicurio/apicurio-registry/blob/master/storage/kafkasql/src/main/java/io/apicurio/registry/storage/impl/kafkasql/KafkaSqlRegistryStorage.java#L309

https://github.com/Apicurio/apicurio-registry/blob/master/storage/kafkasql/src/main/java/io/apicurio/registry/storage/impl/kafkasql/KafkaSqlRegistryStorage.java#L362

[carlesarnal]

Another option is to introduce a new Authentication context CDI bean. That bean could hold authentication information such as the currently authenticated user/principal. That way the storage layer could make decisions based on that. The auth context bean would need to be updated at whatever point makes sense, on a per-request basis (so the state of the auth context bean would probably be thread-local).

The advantage of this is you don’t need to change the storage signatures, but it also might put us in a good position in the future once we have more advanced Authorization scenarios (e.g. the user’s roles determines what content they have access to, with the roles being encoded inside a JWT).

Actually, and since we’re already using the quarkus oidc extension, that kind of bean is already present. I’ll try to inject it, test it and see how it looks. See this for more info.

[EricWittmann]

Another option is to introduce a new Authentication context CDI bean. That bean could hold authentication information such as the currently authenticated user/principal. That way the storage layer could make decisions based on that. The auth context bean would need to be updated at whatever point makes sense, on a per-request basis (so the state of the auth context bean would probably be thread-local).

The advantage of this is you don’t need to change the storage signatures, but it also might put us in a good position in the future once we have more advanced Authorization scenarios (e.g. the user’s roles determines what content they have access to, with the roles being encoded inside a JWT).