Rule #2 sounds dumb. If there can't be a single source of truth, for let's say permission checking, that multiple other services relay on, how would you solve that? Replicate it everywhere? Or do you allow for a new business requirement to cause massive refactors to just create a new root in your fancy graph?

▲

jayd16 3 days ago | parent | next [-]

Services handle the permissions of their own features. Authentication is handled at the gateway.

Not sure if I agree its really the best way to do things but it can be done.

▲

solid_fuel 3 days ago | parent [-]

That implies that every service has a `user -> permissions` table, no? That seems to contradict the idea brought up elsewhere in the thread that microservices should all be the size of one table.

▲

whstl 21 hours ago | parent [-]

Well, depends on the permission model.

For RBAC or capability-based permissions, the gateway can enrich the request or the it can be in (eg) a JWT. Then each service only has to know how to map roles/capabilities to permissions.

For ABAC it depends on lots of things, but you often evaluate access based on user attributes and context (which once again can be added to the request or go into the JWT) plus resource attributes (which is already in the microservice anyway).

For ACL you would need a list of users indeed...

Something like Google Zanzibar can theoretically live on the gateway and apply rules to different routes. Dunno how it would deal with lists, though.

After writing it down: sounds like an awful lot of work for a lot of cases.

Btw: the rule for microservices that I know of, is that they must have their own database, not their own table.

	▲	jschorr 19 hours ago \| parent [-]
		Dealing with lists is complicated with ReBAC, but possible. See my other comment on this: https://news.ycombinator.com/item?id=45662850

▲

kaashif 3 days ago | parent | prev [-]

This is exactly the example I thought of and came here to post.

The rule is obviously wrong.

I think just having no cycles is good enough as a rule.