Re:Authorization in a Microservices World
by lukeramsden on Friday April 01, 2022 @04:13PM
(#30882810)
The way it's done at my current company is that services do their own minimal authorisation based on their own business logic, if any at all, and the rest is done by a dedicated "policy service" that is called by the request composer (which is the only service the FE calls) to do very advanced checks on what individual users are and aren't allowed to do, with the policy service being configurable through YAML "policy documents". It seems to work very well for the colleagues of mine that work on it.
[ Parent
| on HN ]
Re:Authorization in a Microservices World
by coredog64 on Friday April 01, 2022 @07:42PM
(#30884468)
A former employer (top 5 investment bank) did this as well. There was a central store of identity (well, two: One Windows and one non-Windows). Your application then included it’s own policies (written in Prolog) that could reference identity details and/or deep intrinsic request details. As soon as Prolog hit a condition where it couldn’t unify your request and the policy, you got a no.
There’s a similar OSS implementation (OPA) targeting mainly k8s but allegedly useful generically that uses Datalog.
Nice!
Is the request composer responsible for checking the authorization data? Like what roles/permissions the user has?