5 posts tagged with "Data"

RBAC answers "may this caller call this method". It has one blind spot, and everybody meets it the first time a customer service user opens a list and sees every customer in the company: the method is allowed, and the records are all of them.

An access-control list closes that gap without touching the method check. It is opt-in per table, evaluated in SQL as part of the query, and it can only ever take permission away — which is the property that makes it safe to add to a running system.

Start with a number, because the number is the idea. A role in Blong is a bit, numbered 0 to 1023. A caller holds a set of them, the signed token carries that set as a base64 bitmask under the per claim, and the gateway answers "may this caller invoke this method?" without asking a database anything.

Six roles in a development database look like this — the bit beside the name, and the mask the login hands out:

access_role:        0 Admin · 1 Manager · 2 Customer Service · 3 Customer · 4 Guest · 5 NoLogin
access.user → per:  testAdmin [0] AQ==   testViewer [3] CA==   testGuest [4] EA==   testNoLogin [5] IA==

AQ== is one byte with bit 0 set. CA== is bit 3. The claim is the whole authorization payload a request carries, and it travels in a header rather than in a session lookup — which is what makes the check cheap, and what makes revocation a separate problem that sessions exist to solve.

A signed token is a lovely thing right up to the moment you need to take it back. It cannot be revoked, it says what it said when it was minted, and it stays valid until it expires — which is why "stateless JWTs" and "we need to log this user out" cannot both be true without a second mechanism underneath.

Blong's answer keeps the token as the fast path and adds a database-backed session behind it, with rotation, inactivity, revocation, and an audit trail written at the one place every controlled operation passes through.

Ask a system of any age a simple question — "which organisations is this person connected to?" — and you can watch it fail in a specific way. The person exists three times: once in the HR tables, once in the customer records, once in the login store, and the three rows share a name and nothing else. The connections are worse: a membership is a join table here, a foreign key there, a JSON array in the third place, and no query can follow the chain without knowing which of them it is standing in.

Blong puts people, organisations, units, roles, users and actions in one graph. An entity is a resource; a relationship is an edge between two resources; and the realms that describe them are lenses over that graph rather than separate stores standing beside it.

Every migration directory carries the same three problems, and nobody who has maintained one for a few years still argues about them. The files are ordered, so the order matters and a merge can put two of them side by side. The history is append-only, so the schema you have is the sum of everything ever written rather than a description of what is wanted. And the DDL that stores a record is written twice — once in a migration, once in the validation that accepts the request — so the two drift the first time somebody adds a field on one side only.

Blong deletes the second description and the ordering problem with it. The TypeBox object a handler already uses to validate its input is the table. There is no migration directory, no version table and no numbered prefix to invent.