Which micro service has the ‘@ProcessingGroup’ annotation tied to an Event Handling Component? Is that within the service from which the event originates or on the service which receives event from the ‘SpringAMQPMessageSource’ you’re leveraging? Or, are you still containing both in the same application and adding the @ProcessingGroup is in a testing phase?
Regardless of the exact set up, my hunch is that you’ve still got one real application, wherein the @ProcessingGroup ties your Event Handling Component to the SpringAMQPMessageSource, and not having the @ProcessingGroup annotation ties your Event Handling Component to a default SubscribingEventProcessor.
Taking the stance this set up is true, the default SubscribingEventProcessor makes it so that the thread publishing the command (which most likely already has the SecurityContext attached) is the same thread which handles the event in your Event Handling Component. Hence, you’ve still got the SecurityContext set when not using the @ProcessingGroup.
Once you do add the @ProcessingGroup annotation, the Event Handling Component is automatically handled by the SpringAMQPMessageSource, which is a different thread then the command-publishing-thread which does contain the SecurityContext.
Hence, it seems like the @ProcessingGroup is the trigger for having a SecurityContext or not.
You can solve this issue by adding the required information for the SecurityContext (guessing a token) to the metadata of the Rabbit message.
On the receiving side, you can then add a MessageDispatchInterceptor which pulls that information out of the metadata and populates the SecurityContext on that side.
Hope this helps you out Denis! If any of my assumptions are incorrect, please tell me so.