> Suppose you decide to add teams to gitcloud, so different teams in an organization can have different permissions. Will you be able to find all the functions and queries you need to modify in order to make teams work properly? Do you want to have to do that?
> This is why we introduced Polar, our declarative DSL for authorization. Polar allows you to separate your authorization logic from your application logic and express it in a language that is purpose built for authorization. A simple Polar policy looks something like this:
First, I appreciate that it is the Polar "programming language" and not yet another kind of stupid YAML DSL.
However: you seem to target developers. Why do you force me to leave my IDE and use your "rules editor"? Can I not write all those things in my IDE, with all the support it brings, and integrate this into my CICD flow? (yes, there is the .polar file, but why force me to jump through hoops?)
Then, why did you create a new DSL and not a merely a (de-)serializable datastructure (which will indeed look like a dsl)? One, that is powerful enough to represent the capabilities you need. Then, I could in fact use any language (library) of my choice and create the rules from this language, which just has to create the datastructure.
Or, backwards: why do you think authorization is so special that it deserves a custom language? Is it more special than performance-testing, logging, auditing, debugging, metrics and so on?
Apart from that, I really like the `yes, if` idea! Would be nice to hear a bit more about that (unfortunately, the article pretty much ends there). Such as: how to deal with actions that change things and can (or must) potentially be run before the authorization is completed and such.
> However: you seem to target developers. Why do you force me to leave my IDE and use your "rules editor"? Can I not write all those things in my IDE, with all the support it brings, and integrate this into my CICD flow? (yes, there is the .polar file, but why force me to jump through hoops?)
Hey valenterry! Oso CTO here. You can absolutely write policies locally and integrate this with CI/CD. We have vscode extension for the former, and CI tools for running local dev environments and CI for running this locally or in CI or whatever.
The UI is mostly nice for getting started development experience, e.g. it integrates directly with Oso Cloud without needing to configure credentials.
> Then, why did you create a new DSL and not a merely a (de-)serializable datastructure (which will indeed look like a dsl)? One, that is powerful enough to represent the capabilities you need. Then, I could in fact use any language (library) of my choice and create the rules from this language, which just has to create the datastructure.
We have a post on this coming soon! The short version is that Polar is a logic language based on Prolog/Datalog/miniKanren. And logic languages are a particularly good fit for representing the branching conditional logic you often see in authorization configurations.
And it made it easier for us to do custom work like add inline policy tests.
> Apart from that, I really like the `yes, if` idea! Would be nice to hear a bit more about that (unfortunately, the article pretty much ends there). Such as: how to deal with actions that change things and can (or must) potentially be run before the authorization is completed and such.
We typically recommend authorizing in two places: at the start of a request, and then when fetching data.
Hey, thx for your answer. I really like to see that you are building upon existing logic languages not totally inventing your own. I think you should market it as that, because many people (like me) have been burned by companies that thought it would be a good idea to invent a completely new language (or even DSL) from scratch.
I think you should also focus on making integration with existing code as easy as possible. I know there even is one of the more research-class PLs that has first-level support for running small prolog-like scripts within other more imperative code. Essentially that is exactly what you guys do, just natively built into the language (which obviously you guys can't do).
Essentially, if the language is simply enough, I'd like to define and build both the facts as well as the logic from within my own programming language, rather than having to use your web-editor or other tooling to get support for syntax and things like that. Then, if I have a usecase where my own language is insufficient or annoying, I can still write "plain" code in your language if needed.
> We have a post on this coming soon! The short version is that Polar is a logic language based on Prolog/Datalog/miniKanren. And logic languages are a particularly good fit for representing the branching conditional logic you often see in authorization configurations.
Ha, I've been playing around with Biscuits (https://www.biscuitsec.org/) and was writing up a blog post on using them in a git forge. When I saw the Polar data units described as "facts" and read your end to end example (https://www.osohq.com/docs/tutorials/end-to-end-example) I thought "Oh this looks very similar". I will say - I do like how Polar seems to type stuff and provide some concepts that Biscuits force you to build out on your own, that's pretty neat.
What is the proof of identity in Polar? Is it something like a token in Biscuits? I'm curious if you can do things like add caveats to reduce what the token is capable of as it gets handed off to different systems. I consider that one of the "killer use cases" of biscuits.
Biscuits are really cool, one day I plan to try and convince Geoffroy to integrate Polar for policies :)
Currently Biscuits + Polar are ideologically similar but with distinct use cases at the moment. Oso is a central service that your backend speaks to whereas biscuits are decentralized cryptographic tokens.
So Oso API calls are all done with service-specific API keys, and don't need a proof of identity beyond that.
My mental model for tokens like biscuits is that they work like a "decentralized cache". I.e. you can take an authentication/authorization decision, sign it, and provide it to a client. They can reuse that decision at services without the service needing to reach out to the authN/authZ provider again.
It would play _really_ nicely together with the Distributed Authorization concepts we're talking about here: a client could ask the authz service: "I want a token for managing issues". The authz service/Oso could respond with a partially evaluated policy, like: "this token grants the user access to issues that belong to repository 1, 2,3, or issues that they are the creator" (encoded as facts to check a la biscuits).
When receiving that token, the issues service would know what filtering to do locally, without having to reach out to Oso.
The information passed around between the services mostly stays the same, but rather than make an API call each time, the necessary authz information is encoded in the biscuit token.
And then next level: biscuits can cross federation boundaries and be attentuated, etc. So it really starts unlocking novel ways to integrate application-level authz with infrastructure-level authz.
There's definitelt some cool use cases we could collaborate on. One thing I'm looking at more deeply right now is tokens carrying the necessary data as they go through the system,to make sure one call does not see some of it rights change dynamically when going from service to service
Any such IDE needs a way to communicate with the services that are going to enforce the permissions. The DSL is a good way to do this. It allows inspection, diffing, and access by other tools, instead of being locked away in some hidden IDE binary structures.
Edit: But no IDEs will yet have any graphical tool to assist in rule development and checking. So the fact that one is provided, is better than it not existing at all. But you can always edit the DSL manually, if need be. They explicitly state that their rules-editor can sometimes be limited:
"The Rules Workbench, a visual rules editor that you can use to model most of these patterns"
First, I appreciate that it is the Polar "programming language" and not yet another kind of stupid YAML DSL.
However: you seem to target developers. Why do you force me to leave my IDE and use your "rules editor"? Can I not write all those things in my IDE, with all the support it brings, and integrate this into my CICD flow? (yes, there is the .polar file, but why force me to jump through hoops?)
Then, why did you create a new DSL and not a merely a (de-)serializable datastructure (which will indeed look like a dsl)? One, that is powerful enough to represent the capabilities you need. Then, I could in fact use any language (library) of my choice and create the rules from this language, which just has to create the datastructure.
Or, backwards: why do you think authorization is so special that it deserves a custom language? Is it more special than performance-testing, logging, auditing, debugging, metrics and so on?
Apart from that, I really like the `yes, if` idea! Would be nice to hear a bit more about that (unfortunately, the article pretty much ends there). Such as: how to deal with actions that change things and can (or must) potentially be run before the authorization is completed and such.