I am wondering about security. I come from the Postgres world. Postgres is able to control data access inside the database. How is data access (authorisation) controlled in TerminusDB?
we’re actually working on finishing off the capabilities system for decentralized management now. There is an internal system database which contains a model of user -> role -> organization -> database -> capabilities - it’s fairly simple and the permissions themselves are currently limited in granularity to fairly unabstracted API endpoint operations (branch, push, pull, read_commit_graph, etc) but it uses OWL inference to enable complex nestings of organizations and correspondingly fine-grained roles. We’re just about to roll out the capabilities API publicly. It supports basic_auth and JWT for inter-server authentication. We’re still getting there, but class hierarchies and inference are really good building blocks for efficient specification of access control models. In terms of broader security - a major goal of our architecture was to allow us to completely separate the revision control logic from the contents of databases. All the revision control operations are blind as to the contents of the databases that they are operating on - the layers subsystem encoded in terminus-store only needs to read the commit graphs to know how to correctly merge, branch, rebase, clone, etc. Nothing in that sub-system loads the contents or needs to query it etc. In the short term what this means is that, we can deploy a secure sharing service that can treat databases as compressed edge-cacheable static file content, with no actual database engine deployed that can interpret them. From the point of view of an open source database and a bottom-up sharing service, this makes a lot of economic sense too - we can afford to support a very much greater volume of free and cheap data content if all of the compute is done on the users’ database engine and all we’re doing is securing the updating and distribution of a bunch of static files.
From a general architectural and most practical purposes this is good, but we would like to be able to offer stronger security guarantees on top of the architectural independence of components. One of the next two features that we are focusing on in core db currently is replacing the ids of content layers which are currently random with content-addressable hash-chains - cryptographic signatures of commits follows, then encryption of all non-commit-graphs at rest, without decryption for revision control operations, then encryption of commit graphs through revision control operations.
That’s the plan anyways - still a long way to go, for sure, but good to know where you’re trying to get to! There’s good economic and practical reasons to take this route too - from our point of view, the more that we can provide strong cryptographic guarantees that we cannot read user data, the less people have to trust our good will and the less incentive there is for others to try to twist our arms.
I am looking to implement state-based and role-based authorisation in an information system so that I we can use sophisticated workflows. Doing this in Postgres means that the DB engine governs all the authorisation for us, with no additional business logic required. That is what I would like to do in TerminusDB as well.
Yes, this is very doable with the new capabilities API - would be interesting to compare and contrast with postgres - I feel that inheritance and inference will make it more efficient in TerminusDB.