samjs

9 ms·

1. 61.▲
   by samjs 6y ago

   In general, you shouldn't really need to pass in large input objects to oso - it operates over the application data. What this means practically is either the data is processed through whatever data access layer you have (i.e. SQL, or
2. 62.▲
   by samjs 6y ago

   We talk about this in our design principles [1]. But I'll give you a summary here too. We often use GitHub as an typical use case [2]. In GitHub you might be able to merge a PR in a repository because you are the repo owner, or you wer
3. 63.▲
   by samjs 6y ago

   Absolutely. I think it would look a little different, but at a high level would achieve the same goals - a single place to see policies and auditing of decisions. We've done some internal proof of concepts of this, and have discussed i
4. 64.▲
   by samjs 6y ago

   Yep, you're right on this one! We went with Rust because we wanted to make it embeddable in other languages. And on the policy language. Polar is indeed a prolog variant. You can see pretty early we took the decision to diverge from a
5. 65.▲
   by samjs 6y ago

   I will say though: OPA is an awesome project and we drew a bunch of inspiration from it early on. I'm excited about more people being aware of the power of declarative policy as code :)
6. 66.▲
   by samjs 6y ago

   (oso CTO, somewhat biased) > The programming language specific code just is some plumbing for accessing the policy agent. If you want to make policy decisions over your application data you still need to work out a way to move it into th
7. 67.▲
   by samjs 6y ago

   Hey denysvitali. oso CTO here. oso was designed to be embedded directly in applications as a library. So there's no additional service to run to use it to make authorization decisions in an application. The other part is that oso polic
8. 68.▲
   by samjs 6y ago

   Hey all! I'm Sam, CTO at oso. Thanks to OP for posting this. A very pleasant surprise to wake up and find this here :) I'll be around to answer any questions people have, but you can also find myself and the team in our community
9. 69.▲
   by samjs 6y ago

   Hey! oso cofounder/CTO here. You're right, and this is something we've discussed a bunch. Our current view is that: 1. Allowing teams to standarise on an _approach_ and a library in the first place is a huge step up from indi
10. 70.▲
    Building a runtime reflection system for Rust (Part 2)(osohq.com)

    5 points by samjs 6y ago|0 comments
11. 71.▲
    Building a runtime reflection system for Rust (Part 1)(osohq.com)

    6 points by samjs 6y ago|0 comments
12. 72.▲
    by samjs 6y ago

    Congrats on the launch! We're building stuff in a similar space! Would be cool to chat and swap ideas: we're https://www.osohq.com , I'm sam@ the same domain.
13. 73.▲
    by samjs 6y ago

    Thanks :) Right now the idea is you would treat policy files like source code. So any changes should go through CI/CD to be pushed out to production. Any dynamic data can be managed directly through the application, and easily referenc
14. 74.▲
    by samjs 6y ago

    Thanks!
15. 75.▲
    by samjs 6y ago

    oso could use tokens stored in another system from within your policy to make authorization decisions. However, it isn't a secrets management tool, so we wouldn't recommend using it to store authorization tokens for the same reas
16. 76.▲
    by samjs 6y ago

    Thank you! We chose Rust for a few main reasons: - It's an ideal language for writing security-focused software given that it eliminates memory safety bugs (a leading cause of security vulnerabilities in the wild). - Authorization is g
17. 77.▲
    by samjs 6y ago

    1) In the near future: JavaScript/TypeScript (via Web Assembly), Go, Rust. Longer term, many more! 2) Absolutely! You could use it to extend your existing authorization code or slowly replace the existing code piece-by-piece or use oso
18. 78.▲
    by samjs 6y ago

    Thanks :) Polar is inspired by Prolog, a logic programming language, and designed to express authorization policies in a declarative style. One of the main things we wanted was a language that embeds well so that Polar can use types from
19. 79.▲
    by samjs 6y ago

    Thank you! Sure, so one thing would be that CEL looks to be designed for writing expressions inside something else - like configuration files or other kinds of policies. So for example, its used within Firebase security policies, which are
20. 80.▲
    by samjs 6y ago

    I'm the cofounder/CTO of oso. Today we're opening oso up in Developer Preview and we're keen to hear your feedback. In our earliest discussions building oso, we knew we wanted to build something to make it easier to add
21. 81.▲
    Show HN: oso – Open-Source Policy Engine for Authorization(osohq.com)

    44 points by samjs 6y ago|16 comments
22. 82.▲
    Announcing the Official MongoDB Rust Driver(mongodb.com)

    13 points by samjs 7y ago|1 comments
23. 83.▲
    by samjs 9y ago

    I wrote on a similar topic [1], about writing system libraries in Rust with a C API and bindings to other languages. Which covers a bit of this, plus some of the sharp edges of FFI. Most of the trickier parts of it are covered in the FFI om
24. 84.▲
    by samjs 9y ago

    The OP converted into this format: https://regexcrossword.com/playerpuzzles/595e5542d2433