kamu-data
Private Datasets: integration of ReBAC into OSO components
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
queryorsearchAPIs), 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
- Implement updating of internal OSO storage so that during queries it contains up-to-date data (actors, resources)
- If we decide not to stay:
- Analyze the migration path to our own abstractions
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.
Please loop me into any design discussions on this topic - I'm very interested.
Fixing a fact: it was decided to stay with OSO, at this point in history