7 ms·
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 do
by lukeramsden 5y ago
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.
- samjs 5y agoNice! Is the request composer responsible for checking the authorization data? Like what roles/permissions the user has?
- gedy 5y agoNot the OP but we did similar and this front end gateway/"backend for front end" would do the roles checks, yes. Back end services could do course grained checks if needed.
- coredog64 5y agoA 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.