This message was deleted.

@Zac Policzer @Felix GV I am starting a POC on my fork (I didn’t send the PR against LinkedIn/Venice because it would need some rebase) https://github.com/datastax/venice/pull/4/files The idea is to introduce an AuthenticationService to separate Authentication and Authorisation

Will take a look. As it happens I started looking at this last Friday. It seems while the original intention was to have AuthorizerService supersede DynamicAccessController, other devs have added additional functionality into the old interface 😓 so now we've got some divergence (where originally AuthorizerService was a superset of the api's of DAC). My plan at the time was to extend AuthoerizerService (into a v2) to include the new api's and make it a sueprset interface once more, and then set about either making an adapter class or straight swapping out the old interface. Notion was to not break our internal dependency. That said, I think I like your approach more, it will probably be ultimately easier to use in the code. Routers and Servers don't need to be privy to the management aspects of this (only the controller does), and therefore in this approach need not be on the hook to instantiate all bells and whistles. And then again splitting the authentication and authorization would give us flexibility on how we parse the principal. In LinkedIn internal this isn't a natural approach to take as our internal security library actually clubs these notions together for utility of downstream dependers.

I can rebase it on Wed