The setup:
1. Master auth_service service holds master copy of Groups database.
2. Some other service (e.g. isolateserver or whatever) acts as a client in
Groups database replication and receives read-only copy of Groups database.
3. The client service may use some sort of service-specific Access Control List
(e.g. mapping (subject, action) -> list of groups names).
4. Master auth_service currently has no idea about ACLs implemented in
individual services.
Groups can be deleted. Which means it is very easy to end up in a situation
when ACL of some service is listing a group that no longer exists. It can be
particularly bad if it is a "negative" ACL, e.g. "allow for everyone except
group X", since missing group is considered empty.
How it can be avoided:
1. Forbid group deletion completely. It can lead to a lot of crap in the DB.
2. Provide a way for linked services to notify primary auth_service about list
of groups they really use. That way primary auth_service can at least warn a
user that the group is in use when they try to delete it. Since modifying ACLs
is a rare operation, auth_service may expose REST API endpoints to be called by
linked services directly, so that main chunk of code that tracks groups usage
can be kept centrally in auth_service implementation.
Original issue reported on code.google.com by vadimsh@chromium.org on 26 Jan 2015 at 11:48
Original issue reported on code.google.com by
vadimsh@chromium.orgon 26 Jan 2015 at 11:48