[jkaptur]

What an evocative example! Before reading your links (sorry! They're long. I added them to Pocket), I just don't see how "allowed to leave an emoji reaction to an issue inside a repository belonging to an organization" could be anything but application logic. That is, all of the logic should be in the application (except authentication). Every noun in the sentence is application-specific! Perhaps the organization has repository-specific blocked-users lists, and disallowed-emoji lists, and (in the application) repo owners can modify the disallowed-emoji list (subject to approval from the organization owners, of course!).

It seems like building a service that tries to abstract all that (the emoji is an "attribute" of the "action" to a "object" that has an "owner" that has "rules") is doomed to succumb to the inner platform effect. The only solution I can see is to build a general rules engine, but, in my experience, those tend to just be complicated, hard-to-read ways to implement logic that should just be code.

[samjs]

> I just don't see how "allowed to leave an emoji reaction to an issue inside a repository belonging to an organization" could be anything but application logic.

I think it's absolutely fair to say that authorization logic is a subset of application logic! The question is whether it's possible to separate any of the authorization logic from the application.

There are two reasons you might want to do that:

1. Separation of concerns (true whether monolith or microservices) 2. You have authorization logic shared across multiple services.

(1) is still a hard problem, but you can be a little less rigorous about it. (2) is where it gets really fun.

Continuing the example, that repository-specific blocked-users lists is _probably_ going to be needed across every other service.

I don't think any of that contradicts what you're saying, just clarifying that "in the application" might still mean you want to extract the shared logic into a service.

But to get to your last paragraph: yes it's definitely hard to build a service that's both sufficiently generic to handle all the kinds of authorization use cases people typically need to do.

You'd be surprised though at how many use cases fall into very similar patterns. We have some internal (soon to be external) documentation where we managed to get to about 20 distinct patterns -- from the common one like roles, and groups, to less common ones like impersonation and approval flows. And most of these share the same 2 or 3 distinct primitives (user is in a list of blocked users for a repository, emoji is in the disallowed-emoji list, etc.).

So you can build something less abstract than a general rules engine, but that still saves you the work of building from scratch for the nth time a roles system or a deny list.

[derefr]

> that repository-specific blocked-users lists is _probably_ going to be needed across every other service.

Rather than a service acting as a shared upstream for multiple microservices, you might want to put this kind of generalized authorization into an API Gateway service that sits in front of multiple (internal or external) microservices.

Compare/contrast: blocking malicious origin IP addresses in a firewall appliance. But substitute "IP address" with "API key", and "firewall appliance" with "load balancer."

[derekperkins]

Then anyone inside your network has unrestricted access. That's why almost all security innovation and adoption is moving away from trusted boundaries. It can still play a role, in conjunction with other layers.

[derefr]

To be clear, I'm not talking about an VPC-edge WAF; I'm talking about a service that sits in front of — and encapsulates — only the specific microservices that require it. An internal ingress controller, in k8s terms.

And also, to be clear, the services would still do domain-object policy-based authorization themselves. The point of such a multi-microservice API gateway is to optimize universal, pre-authentication, static-credential-based denials (e.g. blocking specific API keys, rather than blocking specific users) out of the critical path, such that users can't DoS your backend with 403-generating requests.

[mooreds]

> You'd be surprised though at how many use cases fall into very similar patterns.

I look forward to seeing that pattern list. I'm in an adjacent space (an authentication server offering RBAC) and am constantly amazed at the intricacies of many orgs authentication needs.

I suspect that common patterns can take care of 95% of authorization needs, but I imagine there'll need to be an escape hatch for the 5% that are really super business case specific.

[anamexis]

Super insightful, thank you!

One concrete example of completely separated auth is AWS. It would be quite the nightmare if each AWS service had its own authorization system. Centralizing that management in IAM makes it... manageable (and only barely at that).

[derefr]

Even then, that only covers authorization for things in AWS that fit the general shape of control-plane API calls. There are endpoints in AWS that don't fit that shape, which do their own thing for auth (see e.g. S3 uploads with signed URLs.)

[jagged-chisel]

But that's the difference between authentication and authorization - sure, you've logged in, and we can verify that, but now we need to know if you're permitted to do what you're trying to do. And yes, authorization will then have awareness of some amount of application/business logic.