Does SecurityIdentityAssociation have to be @RequestScoped?

[knutwannheden]

SecurityIdentityAssociation is the implementation of CurrentIdentityAssociation and is declared as @RequestScoped. I was wondering if it actually has to be request scoped or whether it should instead be implemented using Vert.x context locals.

My background is that we are doing processing using a scheduled method (using @Scheduled), where we had problems with OpenTelemetry. This problem was addressed by making sure the scheduled method is executed on a Vert.x duplicated context (see #28255).

Further, we are also processing incoming Kafka messages, where we sometimes want to set a Quarkus security identity. Currently, this requires that the @Incoming-annotated method is also annotated with @ActivateRequestContext.

[quarkus-bot[bot]]

/cc @sberyozkin

[sberyozkin]

Hi @knutwannheden I'm not sure I understand the consequences, not sure such a refactoring is necessary given that adding @ActivateRequestContext, even though it requires some effort, works...

[knutwannheden]

Adding the annotation isn't that much work, it may just be a bit of a surprise for the user, since the concept of requests doesn't really exist in that sense when processing Kafka messages.

I was just thinking the decision to use @RequestScoped for SecurityIdentityAssociation may have been a decision from the early days, which maybe could benefit from being revisited.

Pinging @cescoffier here, since he worked on #28255.

[sberyozkin]

The thing is that SecuriryIdentity represents the current user credentials in the current HTTP request. I'm not sure changing these semantics to make them available in the duplicated contexts during the request which will happen at some time later is a good idea right now... It is not even the same user interaction

[knutwannheden]

Also, in relation to this, I have noticed that Quarkus has no explicit "implementation" of the MicroProfile ThreadContext.SECURITY context. I assume that is because it is implemented using the CDI request scope and as such can't really be separated from the CDI scope and thus also can't be propagated (or cleared) independently. (The same basically applies to the OpenTelemetry tracing context, but that is a different issue.)

Maybe supporting MicroProfile ThreadContext.SECURITY would provide a way forward for use cases when the user explicitly wants to propagate that context independently of the request context.

[sberyozkin]

Hi @knutwannheden, Can you please open an enhancement request, for MP ContextPropagation impl to support this type of context ? I don't know how feasible it will be to support it, but tracking it with a dedicated issue would make it move visible

[knutwannheden]

@sberyozkin AFAICT the MP Context Propagation specification already supports this. I think there is just the implementation missing in Quarkus or am I missing something?

[sberyozkin]

@knutwannheden This is what I meant, sorry, have a Quarkus issue, for MP ContextPropagation impl to support this type of context, it was a bit cryptic I agree :-), impl there means Quarkus implementation of MP Context Propagation

[knutwannheden]

See #29703.