3

Usually in spring boot applications, we can use jpa audit to do the tracking. Spring Boot Jpa Auditing

While in microservices architecture, I'd try to avoid involving security in core microservice. Instead, we can do authentication/authorization at api gateway.

While, if the core service didn't get the current login user, we have to find an way to pass the current operator to core services. It could be an user identifier header on the request. Or Maybe we can pass token to core services to let it fetch the login user from auth server.

I am wondering if anyone has handled such case and give out some suggestion.

glytching
  • 44,936
  • 9
  • 114
  • 120
Joe
  • 91
  • 1
  • 5
  • I have heard, in microservices is good to transfer 'transaction key'. It is important for example if something goes wrong, and required is to analyse logs of many services – Jacek Cz Aug 29 '17 at 08:56

2 Answers2

4

If I understand the question correctly ...

  • You have an API gateway in which authentication/authorisation is implemented
  • On successful negotiation though the API gateway the call is passed on to a core service
  • The core services perform some auditing of 'who does what'
  • In order to perform this auditing the core services need the identity of the calling user

I think the possible approaches here are:

  1. Implement auditing in the API gateway. I suspect this is not a runner because the auditing is likely to be more fine grained than can be implemented in the API gateway. I suspect the most you could audit in the API getway is something like User A invoked Endpoint B whereas you probably want to audit something like User A inserted item {...} at time {...} and this could only be done within a core service.

  2. Pass the original caller's credentials through to the core service and let it authenticate again. This will ensure that no unauthenticated calls can reach the core service and would also have the side effect of providing the user identity to the core service which it can then use for auditing. However, if your API gateway is the only entrypoint for the core services then authenticating again within a core service only serves to provide the user identity in which case it could be deemed overkill.

  3. Pass the authenticated user identity from the API gateway to the core service and let the core service use this in its auditing. If your API gateway is the only entrypoint for the core services then there is no need to re-authenticate on the core service and the provision of the authenticated user identity could be deemed part of the core service's API. As for how this identity should be propagated from the API gateway to the core service, there are several options depending on the nature of the interop between API gateway and core service. It sounds like these are HTTP calls, if so then a request header would make sense since this state is request scoped. It's possible that you are already propagating some 'horizontal state' (i.e. state which is related to the call but is not a caller supplied parameter) such as a correlationId (which allows you to trace the call though the API getway down into the core service and back again), if so then the authenticated user identify could be added to that state and provided to the core service in the same way.

glytching
  • 44,936
  • 9
  • 114
  • 120
-2

DO you have code Example. I have tried to pass token from zuul to other module. But I always got null in header in another module.

Rupak Chaulagain
  • 29
  • 3