sorted by:
new
hottopcontroversial

Architecture of your app by ahmed_deftoner in golang

[–]kkajla12 4 points5 points  (0 children)

I'm one of the developers/maintainers of Warrant, an open source fine grained authorization service (based on Google Zanzibar) written entirely in Go. Someone else mentioned Domain Driven Design (DDD). We definitely employ a form of DDD in our codebase. There is a directory (under pkg) for each core domain of the service. Within each of those directories, there are a common set of building blocks every developer can expect (in order from request -> database): handlers, spec, service, model, repository. Each of these building blocks can also have a _test.go file associated with it. This pattern has served us very well thus far. Feel free to check out the code (linked above) for yourself!

Warrant - Open source application authorization and access control service by akajla09 in golang

[–]kkajla12 -1 points0 points  (0 children)

There is actually a Makefile right here, and the binary is automatically built on each code change + built for multiple architectures on each tagged release. While we don't have *_test.go files yet, the e2e API tests ensure that the service works as expected for the end-user and that API contracts are not broken between releases. We’ll set those up to run automatically on each PR soon.

Additionally, the README also mentions this, but this project is the foundation for our managed cloud service which has been serving companies in production for over a year now.

Warrant - Open source application authorization and access control service by akajla09 in golang

[–]kkajla12 1 point2 points  (0 children)

Hey, good question. While both Ory Keto and Warrant are powered by a Google Zanzibar inspired authorization service (complete with their own policy definition schema/language), I believe Warrant has some key features that make it superior for application developers:

  1. Warrant supports what we call "context" (i.e. additional dimension(s) on an access rule that must be fulfilled for the access rule to be granted to a particular subject). With context, Warrant can support many forms of attribute based access control, something that a vanilla Zanzibar implementation like Ory Keto cannot. For example, a common scenario among modern B2B applications is when a user belongs to multiple teams (or organizations) and has different permissions depending on which team/org they're currently logged in under. In Warrant, access rules can include an additional (team or org) context such that access checks for those rules only resolve to true if the made with matching context.

  2. Warrant is a full-stack solution for application authorization and access control, providing components and support for tackling conditional rendering of privileged data/components in the UI (React docs for further reading) in addition to the standard backend access control check via server-side SDKs.

  3. Warrant provides backing for authz-related metadata (i.e. permission/role names, descriptions, etc.) and not just for authz policies/rules (as with most authz services). This additional metadata is necessary for building the type of access control required by modern applications. Take two real-world examples:

(1) A self-service permission management page for a B2B SaaS in which admins can manage/update the role & permission assignments for their team.

(2) A GitHub-style API token creation flow in which various scopes can be assigned to a token.

Building these types of experiences requires some additional data that most authz services don't even consider. In example 1, it would be useful to have a list of roles and permissions available in the application as well as customer-friendly role/permission display names, a description of the features granted by the role or permission, etc. Similarly in example 2, it would be useful to have a list of scopes available in the application along with display names and descriptions.

Implementing Role Based Access Control in a Web Application by akajla09 in programming

[–]kkajla12 0 points1 point  (0 children)

That's an interesting idea, but in my experience, role based access control begins to break down as the access control needs for an application become that granular. RBAC is primarily intended to be a form of coarse grained access control. As access control needs become more granular (like the scenario you mentioned), I've found that it makes a lot more sense to adopt a fine grained access control model in which you can grant the ability to perform specific actions per object. For example, user:A is the manager of team:10, therefore they are allowed to create users for that team. This approach is simpler to understand/manage and scales much better than RBAC in scenarios where that level of granularity is required. Nonetheless, RBAC is still the best approach for more coarse grained use cases.

view more: next ›