Data-driven authorisation

[gsvarovsky]

Data-driven authorisation

It will be possible to have the clone allow or prevent write access to sub-parts of the domain data, based on access control data in the domain. The available configuration complexity will be sufficient to show that it is possible to meet the requirements established in the threat models.

This feature has been developed as a partial implementation of the Symmetric Unilateral Access Control (SUAC) specification.

The concept of agreements has been wired into the core m-ld protocol, representing coordinated changes to state (I explained why such changes are important in my presentation at the NGI webinar on conflict-free replicated data types). Agreements have the property that any concurrent changes are voided – undone and removed from history; however, the intention is that the requisite coordination is conducted prior to submitting an agreement, so that voiding is actually only a fallback to guarantee consistency.

Agreements are normally intended to be triggered automatically in registered extensions to m-ld. In this work we have provided for such extensions (and generally, any extensions) to be declared in the domain data itself. This has been a long-standing goal for m-ld as a whole.

Suitable extensions have then been created to implement access control: defining assignment of permissions to security principals (users) as statutes (sets of data that require agreement to change); introducing the concept of authority as a condition for agreement; and checking both permissions and authority during local and remote operations.

Specification

The changes to the m-ld core, and the extensions, implement and demonstrate most significant features of the proposed SUAC ontology and protocol, with some simplifications and modifications as follows. (Where these modifications are likely to persist beyond this project, we will update the SUAC document to match.)

• The matching of data updates against statutes, permissions and authority has been realised uniformly using SHACL. This has the great advantage that SHACL shapes are canonically defined in RDF, as well as having useful expressiveness; the fluency that results can be seen in the compliance tests (see §Verification). For this prototype we have demonstrated property shapes with a predicate path, while establishing a pattern for much more of SHACL to be supported in future.

Module Structure

The following list items introduce the major moving parts of this prototype; details can be found in the Files changed tab.

1. The core API for agreements comprises the new @agree keyword (see src/jrql-support.ts), which marks a json-rql Update as an agreement; plus the new AgreementCondition interface and its inclusion in MeldExtensions (see src/api.ts).
2. The core protocol support for agreements comprises additional subcomponents of the EncodedOperation type (describing the 'operations' exchanged between clones, see src/engine/index.ts). Operations can now also be signed by a transport security extension (see below), to ensure provenance (also to be explored further in the Traceability milestones).
3. The core implementation of agreements comprises a major overhaul of the SuSetDataset.apply algorithm and the journal classes (src/engine/journal), to support application of agreement conditions, and the ignoring or voiding of operations concurrent with an agreement (see §Major Challenges).
4. Loading of extensions from domain data involved a major overhaul of src/engine/CloneExtensions.ts, including its ability to listen to changes in the domain data.
5. Three (non-core) extensions comprise the access control functionality.
   • The existing transport security extension (see src/security/MeldAclTransportSecurity.ts, renamed from "MeldAccessControlList") is largely unchanged but the API has been updated to allow for signatures on operations.
   • Statutes are implemented in a new extension (see src/constraints/Statutory.ts).
   • Write Permissions are implemented in a new extension (see src/constraints/WritePermitted.ts).

Major Challenges

In realising the proposed SUAC design, a number of significant challenges were either overcome, or characterised and deferred to future research. An overall impression of the complexity can be seen from the number of new considerations added to the security design mindmap!

• [overcome] Voiding of operations (concurrent with an agreement) requires reversing journal entries. It was realised that prior to this work, journal entries did not contain enough information to be reversed. This is because the SU-Set CRDT does not need to track exactly what triples were deleted during forward operation; but when driven backward, the correct triples must be re-inserted. Therefore, the journal has been augmented to track deletions.
• [overcome] The prototyped extensions are realised as classes which have both behaviour (for checking permissions/agreement conditions) and state loaded from the domain. This makes them an interesting microcosm of the equivalent parts of complex apps, especially those using object-orientation as a design pattern. As part of this milestone we explored building a simple experimental ORM toolkit (Object-RDF Mapping) on top of the basic m-ld API (see src/orm.ts).
• [partially overcome] Voiding of operations must only reverse journal entries with any process clock tick greater than that found in the agreement time. However, in m-ld, sequential journal entries may be fused (compressed). A fused entry may cross a process tick found in the agreement. In this case, it's not possible to arbitrarily "cut into" the fusion. In the prototype, the fusion is completely reversed; and if the clone is now missing data prior to the agreement, it goes into a 'recovery' mode (as if it has been offline). We hope to experiment how this solution behaves in practice.
• [deferred] Following-on from the above, another problematic (though hopefully rare) scenario is that the clone does not have sufficient journal to rewind all the way back to the agreement. In this case, the only possibility is to recover to a snapshot. While this should work, it is suggestive of a denial-of-service attack, in which a malicious clone tactically pushes out agreements knowing that other clones will be forced into recovery. Further, it could be combined with the next challenge to mount an integrity attack.
• [deferred] As discussed in the SUAC design, trust during clone recovery depends on the trustworthiness of the recovery collaborator. This is susceptible to malware or otherwise malicious nodes. In particular, snapshots and fused journal entries (both used in recovery) are signed by the collaborator, not necessarily by the originator(s) of the data. Ideally, we need a way to reliably verify snapshot and fusion content that does not depend on trusting a recovery collaborator. Logically, this should be possible, since the creation of snapshots and fusions is done by deterministic algorithms.

Verification

Changes in the source code are thoroughly covered by unit tests, in the test folder. Unit tests are currently run as part of the vercel build (see passed checks, below).

The overall behaviour of the implementation is animated and documented in a new local compliance test, compliance/test/2-agreements.spec.js. This test covers the same set of cases elaborated in the SUAC protocol design. Reading this test gives a good overview of the data-driven gestures used to declare extensions, statutes, agreement conditions and permissions.

Note that the ontology of statutes has been demonstrated using a statute over the hasPermission property of a principal; the full vocabulary would be completed in a future production version.

Next Steps

The next step in prototyping is to demonstrate the use of an external protocol to drive authorisation behaviour. In particular, we would like to require that some changes require consensus: a form of coordination that is does not rely on authority – either of a principal (as in this milestone) or of a node in the network (as with centralised databases & services).

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/m-ld/m-ld-js/JAaZGY9x8dPyrY3yagCnthaA1X2d
✅ Preview: https://m-ld-js-git-security-prototype-m-ld.vercel.app