1

We are creating an security token service using IdentityServer4. Due to audit requirements, we would like to log every succeeded (and failed) login attempt, together with information about the issued token, in particular: which claims the token includes.

The most obvious part seems to turn on (some of) the event types provided in IdentityServer and create a custom event sink where login success and failure can be handled (e.g. logged to a database).

We have created such a sink, but the event passed into the PersistAsync method does only contain information about the user trying to log in and nothing about the issued token. I also find various issued (here, here and here) that mentions the security concerns around supporting token logging, customization of token logging etc., all making me believe that this might not be as straight forward as we hope.

So the question is: Where, if even possible, would be the correct/best place to hook into IdentityServer i order to achieve audit logging of the issued tokens?

Julian
  • 20,008
  • 17
  • 77
  • 108
  • It should be easily accomplished by extending default identity server services for tokens and overriding them in DI. Could also use some custom middleware to inspect responses for tokens which would probably be a less intrusive method. But clearly based on your research security of such logging is a concern for some so you need to evaluate if it is not in your case. – Vidmantas Blazevicius Feb 20 '19 at 20:37

1 Answers1

0

We did this by using the existing events exposed by IDS4 combined with our own and dispatching them via Mediatr to handlers that can then log or take other actions (e.g. email alerts to end users or invoking external integrations). We also added Hangfire to the mix to handle background processing of certain things.

IDS4 --event--> IEventSink --publish--> Mediatr --dipatch--> IAsyncNotificationHandler(s) ---> action

Our custom events --publish--> Mediatr --dispatch--> IAsyncNotificationHandler(s) --> action

The action could be sheduling a hangfire command or writing to a DB etc.

As for context about the current request - since these events are invoked in the context of a request you have quite a lot of ambient info available - primarily the claims for the user in question.

We don't log anything sensitive like passwords, or the tokens themselves but logging the claims is probably fine as those in themselves shouldn't be particularly sensitive.

If you need more than IDS4 gives you then you may need to override their code and inject your own event raising logic. E.g. you could extend DefaultClaimsService and override GetIdentityTokenClaimsAsync to insert your own logic.

mackie
  • 4,996
  • 1
  • 17
  • 17