dolittle-obsolete / DotNET.Fundamentals

Reusable, fundamental abstractions and building blocks
http://www.dolittle.io
MIT License
4 stars 8 forks source link

Add examples of SecurityDescriptors to documentation #230

Closed TomasEkeli closed 5 years ago

TomasEkeli commented 5 years ago

Added documentation showing use of the SecurityDescriptor. Not sure I like referencing the other packages in fundamentals, but this reflects real use.

┆Issue is synchronized with this Asana task

TomasEkeli commented 5 years ago

I can move this to the SDK, but I still think we need documentation around the security descriptor - how do you use this directly? If it's not intended to be used directly - why have it available in Fundamentals?

einari commented 5 years ago

This is a fundamental and extensible building block representing everything security Dolittle. For the .NET SDK, which extends this - it provides functionality related to Commands and Queries. While our Runtime, who is going to govern is also using this fundamental system. We do need documentation specific for the system, but it needs to be on the core functionality and all its moving parts - the SDK part then showing the usage from an SDK perspective, which will be different from C#, Java, Go - while the runtime tapping into the underlying system. It all just looks a bit weird and probably pointless when the separation is not done yet, but we have been carefully layering it all to build for extensibility and decoupling concerns. That being said, we will probably have to refactor some of the fundamentals here when we get deeper into the separation - as I’m expecting us to have screwed up some abstractions.

smithmx commented 5 years ago

The Security stuff isn't the easiest thing to use as there are a lot of moving parts. The hope is that you use the built-in stuff rather than rolling your own (better to rely on IPrincipal, roles and claims than custom stuff). So the basic article should be examples of securing commands and queries based on the IPrincipal object... as you've done, showing securing everything in a namespace and also securing an individual command using the Type securable.

Getting more advanced, the most likely thing is that you want to use a custom object rather than the principal... so the thing would be how to extend that part so that it stays in the same style / flavour. The big gotcha here is that you need to be aware of the lifecycle of your custom object. Every rule gets asked if it applies to the thing being secured (Query / Command) so if you hitting a database this can get very slow. It's up to the client dev to make sure they only retrieve the custom security actor one time per request.

If you want to secure something like a new endpoint where you allow custom services (i.e. something like CommandCoordinator / QueryCoordinator) then it does require a lot of work... would be a very interesting article to write as you'd need to implement security, validation, result and the coordinator...

TomasEkeli commented 5 years ago

moved to learning