Keto relations #3
Conversation
|
|
||
| The core of authorization revolves around permissions, such as 'view' or 'edit', rather than checking relations like 'owner' or 'editor'. The concrete permission is checked against the relationships. Within the Ory Permission Language, permissions are declared as functions inside the permits property of the corresponding namespace. Let's explore how permissions might be outlined for our Document namespace: | ||
|
|
||
| ``` |
There was a problem hiding this comment.
formatting: use triple back tick with ts suffix to enable syntax highlighting.
example:
```ts
class User {}|
|
||
| ``` | ||
| class Document implements Namespace { | ||
| related: { |
There was a problem hiding this comment.
up to this point, the flow of the text was excellent. it was a fascinating story about the Google paper. however, I personally struggled at this point.
I am confused because we learnt about the relation tuples earlier, but this code seems like it has nothing to do with that. why are we not using tuples here? what is the relationship between the tuples and this code? is this code for a specific tuple? what is the purpose of this code? maybe the purpose is to define which relation tuples are legal?
There was a problem hiding this comment.
I thought we would insert relations into a database and it would perform a graph theory algorithm to determine whether a connection across multiple relationtuples exists, that connects the user and the document. however this looks like some good simple old boolean permission checks
There was a problem hiding this comment.
The OPL incorporates both the model (namespaces), and the rules which evaluate permissions by navigating through relations. However, OPL itself does not perform the actual relation traversal. Instead, this is handled internally by Keto. While Keto doesn't directly utilize TypeScript, it operates purely on Go. The OPL is parsed by Keto during its initialization.
This approach is somewhat different from the original modeling presented in the Google Zanzibar paper. That modeling was expressed in a more scientific manner, using mathematical notations and representations. The audience wasn't the everyday developers but more advanced researchers and professionals.
The motivation to use TypeScript (TS) for OPL was to make it more developer-friendly. TypeScript is a widely-recognized language with extensive editor support, making it a more accessible and familiar tool for many developers. This adoption aimed to simplify the tooling and make it easier for the majority of developers to understand and work with.
There was a problem hiding this comment.
I suggest that you tell the reader the goal of the code before you show the code. for example:
"the following code defines a simple permission pattern, which keto then uses to build relation tuples internally." or something similar :)
There was a problem hiding this comment.
I adapted it a bit and added a chapter that handles the creation of relations explicitly.
There was a problem hiding this comment.
much better in my opinion, thanks:)
|
|
||
| ``` | ||
| class Document implements Namespace { | ||
| related: { |
There was a problem hiding this comment.
I thought we would insert relations into a database and it would perform a graph theory algorithm to determine whether a connection across multiple relationtuples exists, that connects the user and the document. however this looks like some good simple old boolean permission checks
| @@ -0,0 +1,273 @@ | |||
| --- | |||
| layout: post | |||
| title: "Exploring Relation-based Models" | |||
There was a problem hiding this comment.
a title is one of the hardest parts about a blog post. here is some feedback:
I think the title could be catchier, to make more people klick on it.
this story about the Google paper is fascinating. maybe the title can be a little more engaging using that story as a hook?
ideas
- how google drive checks permission across millions of documents in 10ms
- learning from google: relation-based permissions scaled to millions of users
- permissons untangled: using relations instead of [old approach]
There was a problem hiding this comment.
Actually, this was the original title: From Google's Zanzibar to Ory Keto: Exploring the Evolution of Authorization Frameworks
But from my perspective that has too much focus on google zansibar, while it is quite interesting part, the main point of the article is to make the integration clear and the zansibar part was just to explain its roots.
Maybe I should think about it.
There was a problem hiding this comment.
- Google's Zanzibar and Beyond: A Deep Dive into Relation-based Authorization
- Standing on the Shoulders of Giants: Relation-Based Authz Inspired by Google Zanzibar
There was a problem hiding this comment.
I think your last suggestions are nice
2 participants
No description provided.