Centralized identity store and authentication broker for web applications. It supports a number of authentication mechanisms and is provided via a http-interface.
PSM implementation and organization within checkpoint sounds very good! I'm a little unsure about two points:
1. Data propagation
Using the river for the propagation of access_group_locations data to every pebble which needs access control sounds a bit wobbly. Queuing is fast, but checkpoint will have no guarantee that access updates reach the purveyor of the data.
Say Alice creates a public post in Grove. Then, two minutes later, she realizes that the post must not be readable by all on the Internets. She then tells checkpoint to constrain readability to a certain access_group. Checkpoint then bottles the chmod-like message and puts it in the river. And forgets about it. There is no handshake involved between Checkpoint and Grove, so Sally has no guarantee that the new restriction is in place in Grove. It will most likely be, but she will have to sweat it out and just pray that the gods of queueing and caching are on her side :-)
2. One mirror for every pebble
I probably don't see the whole picture here, but it sounds a bit on the heavy side to have code and persistence in place in all pebbles in order to handle access restrictions. Will usage between pebbles really be that different? Won't it mostly be: What can Bob do with stuff in path a.b.c?
How about this instead...
All access_groups and the adjoining tables are implemented in Checkpoint exactly as proposed.
A redis DB (or similarly fast key-value store) holds the current access_control_locations.
When some access bit changes, Checkpoint immediately updates this in the redis DB.
We write a slim read-only API which lets Grove and other pebbles query the redis DB to find out if Bob can access path a.b.c. e.g.: PebblePolice.access?('Bob', 'dna.sinister.stuff')
This solution has the following benefits:
Using a TCP connection, and being the only one with write access to redis, Checkpoint will know for a fact that the change it requested is in effect, and immediately so.
We remove responsibility and complexity from the pebbles which consume information about identities and access.
One problem with this solution, though:
Returning search results from a pebble like Grove will be difficult to do in a single pass, because the pebble itself does not have everything it needs to know in order to execute the query in a swift manner.
Maybe this could be solved by writing smart active record scopes where we integrate PebblePolice? How big do we think an access list will be for the typical user?
Just some thoughts on PSM
Pebbles Security Model
PSM implementation and organization within checkpoint sounds very good! I'm a little unsure about two points:
1. Data propagation
Using the river for the propagation of
access_group_locationsdata to every pebble which needs access control sounds a bit wobbly. Queuing is fast, but checkpoint will have no guarantee that access updates reach the purveyor of the data.Say Alice creates a public post in Grove. Then, two minutes later, she realizes that the post must not be readable by all on the Internets. She then tells checkpoint to constrain readability to a certain
access_group. Checkpoint then bottles the chmod-like message and puts it in the river. And forgets about it. There is no handshake involved between Checkpoint and Grove, so Sally has no guarantee that the new restriction is in place in Grove. It will most likely be, but she will have to sweat it out and just pray that the gods of queueing and caching are on her side :-)2. One mirror for every pebble
I probably don't see the whole picture here, but it sounds a bit on the heavy side to have code and persistence in place in all pebbles in order to handle access restrictions. Will usage between pebbles really be that different? Won't it mostly be: What can Bob do with stuff in path a.b.c?
How about this instead...
access_groupsand the adjoining tables are implemented in Checkpoint exactly as proposed.access_control_locations.This solution has the following benefits:
One problem with this solution, though:
Returning search results from a pebble like Grove will be difficult to do in a single pass, because the pebble itself does not have everything it needs to know in order to execute the query in a swift manner.
Maybe this could be solved by writing smart active record scopes where we integrate PebblePolice? How big do we think an access list will be for the typical user?