oso
oso copied to clipboard
osohq
.NET Support
This looks like a great library and I think adding .NET support would be really useful.
Hey, thanks for the issue.
We do plan on expanding the number of languages oso supports and .NET is one we would like to do. Issues like this help us determine which languages and frameworks are most in demand so we can decide how to prioritize our roadmap. Do you have any specific use cases in mind?
@saolsen we've use multiple languages so any AuthZ implementation we adopt has to support our core languages and .NET is one of those.
Cool, yeah we've heard something like that from a few different people. What other languages do you use? Are there any other ones we're currently missing?
For future projects Go support would be required and for old projects PHP support would be a nice to have.
Cool. We have an issue already for a go library https://github.com/osohq/oso/issues/459. Go has had a lot of interest so It's the next one we're going to do. I'll make one for php too. Having these tickets that community members can vote on helps us a lot with prioritization decisions so thanks again.
Here's the php issue if you wanna 👍 that one too. https://github.com/osohq/oso/issues/598 We got asked about php from another person recently too.
Hey, can we get this not .netcore is in version 6 It will be a huge gain for us.
OSO is a great project that fully makes sense for big projects. It would be great to see .net core support and integration with Microsoft.AspNetCore.Authorization authorization model. Having that, I can help with integration into Azure stack (Azure SQL, CosmosDB, Kusto and more).
Our company is a Microsoft (SQL Server / C#) shop, so if we could get .NET support that would enable us to look into doing a POC with Oso.
Would be great to see .NET and C# support in the (hopefully near) future. Oso is a great project.
Hey .NET / C# devs! Just a quick note to say that the team and I are watching this issue closely and we're keenly aware of your interest. Thanks so much for the love and for sharing your interest here – it's super helpful as we think about prioritization. We're balancing a lot of incoming requests for features, and we'll keep you posted on any developments.
Graham (Founder/CEO Oso)
@gregorylyons definitely! If you're familiar with Python, Ruby, or Java, the existing language libraries we have for those will probably be the best template for a .NET one. The first thing to figure out will be how to communicate over FFI with the C API we build in the polar-c-api crate at the root of this repository. E.g., in Ruby, we use the ffi gem.
There's an open question of where community-contributed libraries should live. For framework integrations like https://github.com/bjerkio/nestjs-oso it's a bit easier for them to live outside the main repo since they don't (directly) depend on the Rust core, but if new language integrations are going to live outside this repo we'll need to come up with a way to coordinate changes between the main repo and the satellite projects.
.NET's also an interesting case because we're definitely going to want to have an officially-supported language library at some point... I'm just not sure when at the moment. I could imagine the integration starting as community supported and then at some point migrating to the main repo.
If you want to start poking around on a .NET integration, I'd fork this repo and, when the initial scaffolding is done, submit a draft PR. That would be a good forcing function for us to talk about where the integration should live / how we'll fan out changes from the core to it, and so on.
@gj Appreciate the detailed reply.
Its surprisingly easy to call a c dll. Will have a ponder over the weekend, and see where that takes me.
Re. The project structure, external repo or otherwise, I'm not precious - happy to go with the flow. Will follow your suggestions.
I started a very-WIP fork basically wiring up the C methods to C# over P/Invoke.
I have just started reading more of the Java code, so I am starting to understand how the API is supposed to be used more. Lots of assumptions I made in the beginning were wrong, so those will have to be fixed. Don't know if this is worth making a PR at this point. Also don't know how far I'll get, but if I don't finish, maybe it will help someone else.
@gj, is there any more documentation/examples on how the API should be used? The languages/README.md helps a little, but I'm still not familiar with all the terms and whatnot.
@iinuwa awesome, thank you so much for posting that WIP fork! Even if you don't have time to continue to drive it forward, that'll be a huge help as a reference.
To clarify: you're talking about how to use the polar-c-api API, right?
We unfortunately don't yet have a guide for implementing a new host language library, and I would say that what you're already doing (looking at the way the Java library wraps the C API methods) is probably the best path at this point. We can definitely answer specific questions that come up while you're trying to implement things.
To clarify: you're talking about how to use the polar-c-api API, right?
Yeah. I got some pointers on this Slack thread from @saolsen. I started working on the de-/serialization between C and C#, which is the trickiest part I think. I was able to round-trip a Number/int locally, so the rest of the primitives should come easy. The .NET Reflection for creating classes will definitely take longer.
I've made some more progress on the .NET port. I've got just about 20 unit tests left to implement, and then some refactoring and cleanup. I'll probably need to rebase as well since I'm working off of a 3-month old commit.
So far, there's support for queries with primitives and externals.
Some questions I had:
- Keyword arguments are marked as not supported for Java; is that because the Java language doesn't support them? C# supports named arguments, so it may be feasible to implement.
- There are some Polar tests that refer to
new String("somestring"). .NET'sSystem.Stringdoesn't have a constructor that takes another string. Is support for that required, or is it host-dependent? - Similarly, for lists, .NET uses
.Count()rather than Java's.size(). Should I change the tests to reflect that, or should I implement.size()on list-like objects?
Beyond basic dotnet interop, it would be awesome to have an entity-framework adapter for bulk data filtering. Thats sort of how I stumbled upon Oso - researching how to implement ABAC for lists of data.
Keyword arguments are marked as not supported for Java; is that because the Java language doesn't support them? C# supports named arguments, so it may be feasible to implement.
Yep!
There are some Polar tests that refer to
new String("somestring"). .NET'sSystem.Stringdoesn't have a constructor that takes another string. Is support for that required, or is it host-dependent?
That's probably just demonstrating the use of constructors; if there's another .NET built-in type that's constructable, it would probably be a fine stand-in.
Similarly, for lists, .NET uses
.Count()rather than Java's.size(). Should I change the tests to reflect that, or should I implement.size()on list-like objects?
Changing the tests to use .Count() sounds like the right approach.
I think I have basic Oso/Polar support implemented in .NET I've got all the tests ported from the Java Oso library passing in .NET now, so it should be mostly functional. Haven't tried it on any real world policies though. Unfortunately, I don't think I'll have time to carry this much further, so I'll leave some notes here:
One thing that's tricky is that query results can only be enumerated once; subsequent results will fail, so you have to either iterate once with a foreach or .Select(), or collect the IEnumerable<T> using .ToList() or something.
I think I've set up the build system and CI stuff so that it could be published if Oso, or a third party, finishes this work and releases a library. I haven't tested CI actions, but make -C languages/csharp package should produce a debug NuGet package with the native Rust library embedded within it. Cf. the .github/actions/release.yml for steps to build a release version.
I left other notes in the languages/csharp/oso/TODO.md. The main thing that should probably be done before releasing a beta version somewhere is documenting methods and marking ones as internal. (I think that Java doesn't have a visibility accessor corresponding to .NET's internal, so I think that there are more public methods in the Java library that don't actually need to be public for .NET.) The library should probably also be rebased, since it's about 4 months old now.
I can open a draft PR for this if you want, or I can just leave the fork up, lmk.
I think I have basic Oso/Polar support implemented in .NET
Awesome! I just built the package, and found a very small typo in the csharp Makefile that affects macOS. I submitted a PR.
I will play around with it this evening.
I will play around with it this evening.
So this ended up being more involved than I thought.
I am on an M1 (Apple Silicon) Mac, so even though the package built, as soon as I tried to use Oso I got library not found errors.
Ended up tracking it down to some changes that needed to be made in the csharp project file to embed the libraries in the right place.
Also tried to modify the main Makefile to build for both x64 and arm64 if the host OS is macOS. Not sure if that is the best way or not...
But, I do have it working so that I can instantiate an instance of the Oso class now in my dotnet project.
Hey everybody. We don't have an official version of the oso library for .net yet. But we do have a new library for oso cloud!
To learn more about oso cloud you can check out the docs and try out the sandbox
The .net library is here https://www.nuget.org/packages/OsoCloud you can try it out with a sandbox environment.
If you have any questions or feedback on the library I'd love to here it. You can also book a 1 on 1 to talk about it.
@saolsen can you describe the rationale for using List as the primary data structure instead of type safe objects?
Also, can anyone else in this thread comment on their experience with the new beta dot net client?
We’re evaluating Oso amongst other Auth as a Service products.
