Private Datasets: integration of ReBAC into OSO components

[s373r]

Currently, the heart of the authorization system is OSO components (in particular the OsoDatasetAuthorizer).

The purpose of this ticket is as follows:

• Analyze the need to use OSO further; context:
  • In the case of working with a single dataset, the user (as it is now) is fine
  • But as soon as we want to do vector queries (e.g. for query or search APIs), complications can arise:

    • Data filtering is coming soon for Rust! (c) https://www.osohq.com/docs/oss/rust/guides/data_filtering.html

    • Since OSO has deprecated the open source library, "soon" means "never"
  • Perhaps we can somehow get around this point on our own, we need to research this aspect
• If we decide to stay with OSO, then:
  • Implement updating of internal OSO storage so that during queries it contains up-to-date data (actors, resources)
    • Note: synchronously with an API that can change ReBAC properties
• If we decide not to stay:
  • Analyze the migration path to our own abstractions

[sergiimk]

We should consider https://openfga.dev/ as an OSO replacement.

Analyze the migration path to our own abstractions

Personally I feel that the simplicity of our current auth model is making it look like we could roll our own solution, but as we grow to a lot more object types, a lot more relations, and more tricky models (e.g. with hierarchical aspects) we would need something more mature.

Please loop me into any design discussions on this topic - I'm very interested.