9 ms·

Authorization in a Microservices World

253 points by zaplin 5y ago

DIVx0 5y ago
I've been using Open Policy Agent for this scenario with great success. You can either use it in a AZ as a service setup or embed it into middle ware for a sort of "decision making" library.
- mkdirp 5y ago
  As in OPA determines if a user has access to a resource? Do you have some resources on how to do this?
  - qbasic_forever 5y ago
    OPA has a whole policy language to define how people have access to resources however you please. See details here: https://www.openpolicyagent.org/docs/latest/policy-language/ https://www.openpolicyagent.org/docs/latest/policy-language/
  - ogazitt 5y ago
    You do need to have a strategy for how to load the resource mappings into the OPA engine. If they don't change very much you could embed them in the data.json file of the OPA policy itself. But more often than not, that data is changed often (e.g. when someone grants someone else access to a resource). In that case, you'll need the OPA engine to query an external data store via an HTTP request. Or you can use a resource cache, the way we do at Aserto. Here's a blog post [0] about the challenges we faced when using OPA for application authorization. [0] https://www.aserto.com/blog/the-challenges-of-using-opa-for-application-authorization https://www.aserto.com/blog/the-challenges-of-using-opa-for-...
epberry 5y ago
https://www.osohq.com/ https://www.osohq.com/ is a very interesting company in this space. They have an open source authorization library, and a great blog.
- samjs 5y ago
  Thanks epberry!
emreb 5y ago
Disclaimer: I am the co-founder of Cerbos. Thanks for explaining the problem space so well and referring to Cerbos[1] as contextual solution. We had to build these systems in the past so many times and we were tired of reinventing the wheel. With Cerbos we aim to turn this problem space into configuration rather than code and enable enterprise-grade access management for any application. [1] https://cerbos.dev https://cerbos.dev
- mooreds 5y ago
  If you're looking for an example of how to integrate Cerbos with an auth provider like FusionAuth, to augment a typical role implementation with finer grained permissions, check out this blog post: https://fusionauth.io/blog/2022/01/18/extending-fusionauth-roles-with-cerbos https://fusionauth.io/blog/2022/01/18/extending-fusionauth-r...
kitd 5y ago
If your architecture contains Kafka, you can use Kafka ACLs to authorize access to any resource, not just Kafka ones. Based on a principal, a named resource (derived from, eg, a URL path) and the requested operation, the Kafka admin client can tell you whether there is a matching ACL that permits the request. I've had success doing this.
- dbattaglia 5y ago
  Disclaimer: I work at Elastic. Elasticsearch has a general purpose authorization system as well, based on the concept of "application privileges": https://www.elastic.co/guide/en/elasticsearch/reference/current/security-api-has-privileges.html https://www.elastic.co/guide/en/elasticsearch/reference/curr.... It's an interesting concept I never really considered at previous jobs, to piggy-back the authorization system of some infrastructure already in your stack. On one hand I can see some team members finding it to be a bit of a "smell" since it's pretty far from the original intended use case for something like Kafka or ES, but on the other hand it can free you up from having to build this type of thing yourself from scratch or libraries.
kache_ 5y ago
I've been working as an IAM engineer for my entire career. This is a really good write up on a few ways on how you could handle authorization, but I think it also highlights the challenges with it The more I come across different systems, the more I realize authorization in large distributed systems isn't ever one approach: it has to be tailored for each use case with different tradeoffs in mind. It's often directly coupled to the problem domain you're trying to solve for. It has to be integrated with the data access pathways, _and_ also has to be tailored to the authentication system it deals with, _and_ it has to be tailored for the data-locality model of the overall system. The more authorization problems I solve, the more I realize that my dream of coming up with a generalized authz SaaS service that helps me grease out VC money & a billion dollars probably doesn't really exist. It's different from authentication, because authentication has less dimensions of coupling, and less tradeoffs (Auth0 sold for 6b, Okta worth 18b, both authentication offerings) Maybe I'll figure it out one day. Or maybe this is one of those problem domains that is only solved by an army of engineers
- samjs 5y ago
  Well, I potentially have some good news for you :) There are a bunch of companies who popped up in the last few years to solve this problem. We're one of them -- Oso (I'm the CTO). It's definitely a fun/challenging problem to work on. So if building a generalized authz SaaS is the dream, come join us!
  - flutas 5y ago
    Just a heads up, looks like markdown formatting got into your "go get" command for the golang page. https://www.osohq.com/learn/rbac-go https://www.osohq.com/learn/rbac-go
    - samjs 5y ago
      Good catch, thanks!
- ogazitt 5y ago
  Very much agree that authorization is a more domain-specific problem than authentication... but there are some common patterns that are emerging, and can help reduce how much wheel reinvention has to happen. There are (at least) three of us startups on this thread that are trying to tackle this :) (disclaimer - I'm a co-founder of one of these - Aserto).
avereveard 5y ago
I think this glosses on a very important part, which is just named in passing: "how do you actually know that bob is bob, and how do you trust that?" article answer is 'user role [..] attached to a JWT' but that only really applies if you control your distributed microservice system, if you need to scale to etherogeneus identities you need to get into the magic world of federated authorities and that is where the pain really is.
- Liuser 5y ago
  I agree that identity is important, but I would argue that challenge lies in authn and would be it’s own separate article. This focus was on authz. We are assuming we trust the passed in identity at this point. Eg user has authned, session is established, and we trust that the identity has been passed securely from downstream.
prionassembly 5y ago
It says something about the power of branding that my first eye scan parsed this as "Authorization in Microsoft Word".
samjs 5y ago
Love this article. My favourite part is: > "So the logical thing to do is to implement an authorization service and everybody would be able to use that and keep your precious service boundaries, right? WRONG. Your hell, has just begun! Drawing the right boundary for authorization is near impossible. If I want to check whether the user is allowed to see who left an emoji reaction on a comment response to an issue inside a repository belonging to an organization -- do I store that entire hierarchy in my authorization service? Or do I leave some of that in the application? I've yet to see a good heuristic for the latter. Also, thank you to the author for referencing us :) I'm Sam, Cofounder/CTO at Oso where we've been working on authorization through our open source library for the past couple of years. Authorization for microservices has been a recurrent theme over that time, and we've been furiously writing on the topic (e.g. [1], [2], [3]). We'd be interested in talking to anyone who is currently facing the challenges of authorization for microservices (or really just multiple services). We're building authorization as a service, which you can learn more about here: https://www.osohq.com/oso-cloud https://www.osohq.com/oso-cloud. It's currently in private beta, but if you would rather _not_ speak with us first, there's also a free sandbox to try out the product linked from that page. [1]: https://www.osohq.com/post/why-authorization-is-hard https://www.osohq.com/post/why-authorization-is-hard [2]: https://www.osohq.com/post/microservices-authorization-patterns https://www.osohq.com/post/microservices-authorization-patte... [3]: https://www.osohq.com/academy/microservices-authorization https://www.osohq.com/academy/microservices-authorization
- jkaptur 5y ago
  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.
pachico 5y ago
Please, stop posting this every 2 days.
- ryanklee 5y ago
  This seems like an unfair comment. I looked at the poster's submission history, and it does not show what you are claiming.
  - jessaustin 5y ago
    TFA has been posted three times since it was published 12 days ago. Which seems OK? I'll be more concerned if it gets published at a similar rate going forward, but since it got some upvotes and discussion this time around the submissions might stop. No other piece from this blog has been submitted. https://news.ycombinator.com/from?site=alexanderlolis.com https://news.ycombinator.com/from?site=alexanderlolis.com
    - damethos 5y ago
      I was the one who posted it two times. The second one was an honest mistake. This third time wasn't me but I am glad that someone did.
      - jessaustin 5y ago
        Yes, TFA is definitely what we want on HN. There's nothing wrong with reasonable reposting. In years past, I had been encouraged by the actual HN moderators to repost.
xvinci 5y ago
> "Direct DB reads, outside the domain of each service, is a bad idea and it will be obvious to you why on the first schema change. Please don't be lazy and just say no to this." Good read, but I am not really a fan of that stance. The "separate schema per ms" pattern is an overhead which has to be justified and even paid for by customers (small 50k projects and enterprise grade projects of million $). First and foremost the db is a shared data structure which CAN be used for communication and in a one actor writes and 1..n actors read scenario (especially when all connecting services are controlled by the same team) is typically the simpler and better approach as a start. Schema evolution will also hit you with messaging and APIs which can be done properly in smaller databases as well.
- dboreham 5y ago
  You certainly can have a monolith database, but typically you'll find that many of the Conway benefits of services will be lost as a result.
- mixedCase 5y ago
  A single database instance can host multiple independent schemas. No need to pay for more. Treating a database as an API is more than doable, but the whole team needs to be on point with the necessary shift in expectations, as well as the shift in tooling and best practices.
  - gkop 5y ago
    I was surprised how well treating the database as an API worked at one series A company. We had a single database schema shared by ~5 services. The coordination cost wasn’t bad, and I don’t recall any major issues. It was a big net win for our velocity. I’d do it again, if I had the guts.
  - xvinci 5y ago
    I meant the overhead - in the case of two services - of managing and developing two sets of schemas and a mechanism of data exchange (be it rest apis or queues. both come with a producing and a consuming side). There are many reasons where that makes sense (e.g. both ms have to evolve the shared storage schema in different directions) but I would not do it out of the box every time like the author implies.
wackget 5y ago
Am I the only one who thinks the initial PHP example is just fine? Seriously, you're claiming to "solve" one "problem" by building an entire new system which is inevitably massively more complex and difficult to manage than the "problem" you're trying to solve. Then again, I don't work in enterprise-level environments but to be honest if this is what it's like, I'm glad I don't.
- baq 5y ago
  If it’s fine, you can consider yourself lucky. Authentication and authorization complexity is IME squarely proportional to system and organization size due to network effects inside them. At some point it becomes a significant subsystem in itself and contrary to belief of some it becomes a core business problem, not a checkbox to tick off.
- Liuser 5y ago
  Works fine for 1 application, but what about for thousands of services with many teams? Everything is difficult with scale. We can’t expect every service owner to implement authz correctly, but if we can expose and build tools that help standardize and abstract as much as possible the difficulties of authz then service owners can focus their energy on other things.
cyberpunk 5y ago
Which is why I wont be able to find true love and I’ll die alone. I’ll die alone, without ever knowing it’s my birthday… [0] 0: https://youtu.be/y8OnoxKotPQ https://youtu.be/y8OnoxKotPQ
tored 5y ago
To handle direct database read by multiple micro services you can create views for the different type of authorization checks you need to do. If schema need to change you just update the view.
damethos 5y ago
Author here. First of all thank you for making this article appear in the HN frontpage. I read some interesting comments and approaches but I feel that a piece is always missing (or maybe I did not understood). The piece of how the authorization fetches the necessary application data it needs in order to decide what to do. If you do not need this piece then you can get really creative on how to solve authorization and use an approach that fits best to the needs of your system. But if you do, then I would love to hear more details about this part.
- ogazitt 5y ago
  Great article! Disclaimer: I'm a co-founder of Aserto [0], where we're building a platform for API / microservices authorization. I couldn't agree more that the question of how to get the data to the policy decision point is one of the most interesting and hardest challenges for this scenario. You don't want to replicate the entire world in both your application's data store and your authorization system. But you also want to follow the principle of separation of concerns as much as practical. There may be scenarios where your authorization system has to make calls to an external system, but that can cause availability and latency concerns. Ideally the decision engine has all the data it needs to make an authorization decision, without having to query another system. For filtering scenarios that involve returning too much data to the client (which the client would need to filter locally), you could also imagine the authorization system doing a "partial evaluation" and return you an AST which you can walk and attach as "where clauses" to your query. Here's an interesting read on how to do this with the OPA decision engine. [1] [0] https://www.aserto.com https://www.aserto.com [1] https://blog.openpolicyagent.org/partial-evaluation-162750eaf422 https://blog.openpolicyagent.org/partial-evaluation-162750ea...
nycdotnet 5y ago
An interesting and well written article. I appreciated that they got into horizontal trimming aka field trimming, but vertical trimming like “this person can see all things for all objects except those with property X==1” is a whole separate issue with significant performance issues, particularly around list endpoints. It’s hard to make a one size fits all solution here because sometimes the perf issue is on the frontend (which items can they see) and sometimes on the back end (now for a fragmented set of entities, fetch and return the appropriate information)
raffraffraff 5y ago
Nit: full-proof is an egg-corn. It's fool-proof.
bigbluedots 5y ago
I know this is a space for entrepreneurs, bit it is a little bit annoying to constantly see folks jumping out of the woodwork with "you should try my product!!!!" whenever there is something semi relevant posted
danielovichdk 5y ago
I don't understand why this is considered a bigger challenge than any other relation between small services. If two services is chatty, they should be merged. This can be on several levels, data being one level. Authorization services should not be chatty with other services. And why would they since you ask for claims upon an authentication request. Yes, I meant authentication. And I believe an authorization service is something that has been solved for a long time. It doesn't have other traits than any other services you must collaborate with, that migh be your mistake to look at it like so. The authorization service will give you the claims for the user and, each service will dictate whether the claims are valid and sufficient within the service boundary. Don't look at it ad a special kind of service, because it's really not.
- ranguna 5y ago
  > If two services is chatty, they should be merged. Welp, I guess I'll just merge with stripe then, thanks for the tip!
justinjlynn 5y ago
I've never understood why x.509 authorisation certificates aren't more widely used for this. They're off-line, self sufficiently asserted in the connection context, stacking, are unopinionated about application semantics in terms of authorisation rules/grants/restrictions, have well tested infrastructure for parsing and validation, and can use ocsp stapling for validity, and ct logs for audit. They're used in CERN VOMS, etc. and seem like a great fit for distributed systems doing authorisation but they don't seem widely known or used.
- mozey 5y ago
  Because it's not so easy to setup and manage? Maybe it will become more popular with tools like https://github.com/gravitational/teleport https://github.com/gravitational/teleport
  - justinjlynn 4y ago
    That's true. Honestly, it's probably almost entirely down to the fact that the openssl cli 'Swiss army knife' tool doesn't support them purposefully.
- deleted 5y ago
  [deleted]
h1fra 5y ago
I always wonder how centralised permissions works with listing endpoints. For accessing one resource that's fine, a cached call to any k/v store would work. But when you want to list every items for a resource in a table that contains millions of rows it starts to be more difficult. Without a JOIN you either need to do a costly WHERE IN or filter after the fetch that can results in scanning everything for nothing. Is there any blog post on that?

253 points by zaplin 5y ago

I've been using Open Policy Agent for this scenario with great success. You can either use it in a AZ as a service setup or embed it into middle ware for a sort of "decision making" library.

mkdirp 5y ago
As in OPA determines if a user has access to a resource? Do you have some resources on how to do this?
- qbasic_forever 5y ago
  OPA has a whole policy language to define how people have access to resources however you please. See details here: https://www.openpolicyagent.org/docs/latest/policy-language/ https://www.openpolicyagent.org/docs/latest/policy-language/
- ogazitt 5y ago
  You do need to have a strategy for how to load the resource mappings into the OPA engine. If they don't change very much you could embed them in the data.json file of the OPA policy itself. But more often than not, that data is changed often (e.g. when someone grants someone else access to a resource). In that case, you'll need the OPA engine to query an external data store via an HTTP request. Or you can use a resource cache, the way we do at Aserto. Here's a blog post [0] about the challenges we faced when using OPA for application authorization. [0] https://www.aserto.com/blog/the-challenges-of-using-opa-for-application-authorization https://www.aserto.com/blog/the-challenges-of-using-opa-for-...

epberry 5y ago

https://www.osohq.com/ https://www.osohq.com/ is a very interesting company in this space. They have an open source authorization library, and a great blog.

samjs 5y ago
Thanks epberry!

emreb 5y ago

Disclaimer: I am the co-founder of Cerbos. Thanks for explaining the problem space so well and referring to Cerbos[1] as contextual solution. We had to build these systems in the past so many times and we were tired of reinventing the wheel. With Cerbos we aim to turn this problem space into configuration rather than code and enable enterprise-grade access management for any application. [1] https://cerbos.dev https://cerbos.dev

mooreds 5y ago
If you're looking for an example of how to integrate Cerbos with an auth provider like FusionAuth, to augment a typical role implementation with finer grained permissions, check out this blog post: https://fusionauth.io/blog/2022/01/18/extending-fusionauth-roles-with-cerbos https://fusionauth.io/blog/2022/01/18/extending-fusionauth-r...

kitd 5y ago

If your architecture contains Kafka, you can use Kafka ACLs to authorize access to any resource, not just Kafka ones. Based on a principal, a named resource (derived from, eg, a URL path) and the requested operation, the Kafka admin client can tell you whether there is a matching ACL that permits the request. I've had success doing this.

dbattaglia 5y ago
Disclaimer: I work at Elastic. Elasticsearch has a general purpose authorization system as well, based on the concept of "application privileges": https://www.elastic.co/guide/en/elasticsearch/reference/current/security-api-has-privileges.html https://www.elastic.co/guide/en/elasticsearch/reference/curr.... It's an interesting concept I never really considered at previous jobs, to piggy-back the authorization system of some infrastructure already in your stack. On one hand I can see some team members finding it to be a bit of a "smell" since it's pretty far from the original intended use case for something like Kafka or ES, but on the other hand it can free you up from having to build this type of thing yourself from scratch or libraries.

kache_ 5y ago

I've been working as an IAM engineer for my entire career. This is a really good write up on a few ways on how you could handle authorization, but I think it also highlights the challenges with it The more I come across different systems, the more I realize authorization in large distributed systems isn't ever one approach: it has to be tailored for each use case with different tradeoffs in mind. It's often directly coupled to the problem domain you're trying to solve for. It has to be integrated with the data access pathways, _and_ also has to be tailored to the authentication system it deals with, _and_ it has to be tailored for the data-locality model of the overall system. The more authorization problems I solve, the more I realize that my dream of coming up with a generalized authz SaaS service that helps me grease out VC money & a billion dollars probably doesn't really exist. It's different from authentication, because authentication has less dimensions of coupling, and less tradeoffs (Auth0 sold for 6b, Okta worth 18b, both authentication offerings) Maybe I'll figure it out one day. Or maybe this is one of those problem domains that is only solved by an army of engineers

samjs 5y ago
Well, I potentially have some good news for you :) There are a bunch of companies who popped up in the last few years to solve this problem. We're one of them -- Oso (I'm the CTO). It's definitely a fun/challenging problem to work on. So if building a generalized authz SaaS is the dream, come join us!
- flutas 5y ago
  Just a heads up, looks like markdown formatting got into your "go get" command for the golang page. https://www.osohq.com/learn/rbac-go https://www.osohq.com/learn/rbac-go
  - samjs 5y ago
    Good catch, thanks!
ogazitt 5y ago
Very much agree that authorization is a more domain-specific problem than authentication... but there are some common patterns that are emerging, and can help reduce how much wheel reinvention has to happen. There are (at least) three of us startups on this thread that are trying to tackle this :) (disclaimer - I'm a co-founder of one of these - Aserto).

avereveard 5y ago

I think this glosses on a very important part, which is just named in passing: "how do you actually know that bob is bob, and how do you trust that?" article answer is 'user role [..] attached to a JWT' but that only really applies if you control your distributed microservice system, if you need to scale to etherogeneus identities you need to get into the magic world of federated authorities and that is where the pain really is.

Liuser 5y ago
I agree that identity is important, but I would argue that challenge lies in authn and would be it’s own separate article. This focus was on authz. We are assuming we trust the passed in identity at this point. Eg user has authned, session is established, and we trust that the identity has been passed securely from downstream.

prionassembly 5y ago

It says something about the power of branding that my first eye scan parsed this as "Authorization in Microsoft Word".

samjs 5y ago

Love this article. My favourite part is: > "So the logical thing to do is to implement an authorization service and everybody would be able to use that and keep your precious service boundaries, right? WRONG. Your hell, has just begun! Drawing the right boundary for authorization is near impossible. If I want to check whether the user is allowed to see who left an emoji reaction on a comment response to an issue inside a repository belonging to an organization -- do I store that entire hierarchy in my authorization service? Or do I leave some of that in the application? I've yet to see a good heuristic for the latter. Also, thank you to the author for referencing us :) I'm Sam, Cofounder/CTO at Oso where we've been working on authorization through our open source library for the past couple of years. Authorization for microservices has been a recurrent theme over that time, and we've been furiously writing on the topic (e.g. [1], [2], [3]). We'd be interested in talking to anyone who is currently facing the challenges of authorization for microservices (or really just multiple services). We're building authorization as a service, which you can learn more about here: https://www.osohq.com/oso-cloud https://www.osohq.com/oso-cloud. It's currently in private beta, but if you would rather _not_ speak with us first, there's also a free sandbox to try out the product linked from that page. [1]: https://www.osohq.com/post/why-authorization-is-hard https://www.osohq.com/post/why-authorization-is-hard [2]: https://www.osohq.com/post/microservices-authorization-patterns https://www.osohq.com/post/microservices-authorization-patte... [3]: https://www.osohq.com/academy/microservices-authorization https://www.osohq.com/academy/microservices-authorization

jkaptur 5y ago
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.

pachico 5y ago

Please, stop posting this every 2 days.

ryanklee 5y ago
This seems like an unfair comment. I looked at the poster's submission history, and it does not show what you are claiming.
- jessaustin 5y ago
  TFA has been posted three times since it was published 12 days ago. Which seems OK? I'll be more concerned if it gets published at a similar rate going forward, but since it got some upvotes and discussion this time around the submissions might stop. No other piece from this blog has been submitted. https://news.ycombinator.com/from?site=alexanderlolis.com https://news.ycombinator.com/from?site=alexanderlolis.com
  - damethos 5y ago
    I was the one who posted it two times. The second one was an honest mistake. This third time wasn't me but I am glad that someone did.
    - jessaustin 5y ago
      Yes, TFA is definitely what we want on HN. There's nothing wrong with reasonable reposting. In years past, I had been encouraged by the actual HN moderators to repost.

xvinci 5y ago

> "Direct DB reads, outside the domain of each service, is a bad idea and it will be obvious to you why on the first schema change. Please don't be lazy and just say no to this." Good read, but I am not really a fan of that stance. The "separate schema per ms" pattern is an overhead which has to be justified and even paid for by customers (small 50k projects and enterprise grade projects of million $). First and foremost the db is a shared data structure which CAN be used for communication and in a one actor writes and 1..n actors read scenario (especially when all connecting services are controlled by the same team) is typically the simpler and better approach as a start. Schema evolution will also hit you with messaging and APIs which can be done properly in smaller databases as well.

dboreham 5y ago
You certainly can have a monolith database, but typically you'll find that many of the Conway benefits of services will be lost as a result.
mixedCase 5y ago
A single database instance can host multiple independent schemas. No need to pay for more. Treating a database as an API is more than doable, but the whole team needs to be on point with the necessary shift in expectations, as well as the shift in tooling and best practices.
- gkop 5y ago
  I was surprised how well treating the database as an API worked at one series A company. We had a single database schema shared by ~5 services. The coordination cost wasn’t bad, and I don’t recall any major issues. It was a big net win for our velocity. I’d do it again, if I had the guts.
- xvinci 5y ago
  I meant the overhead - in the case of two services - of managing and developing two sets of schemas and a mechanism of data exchange (be it rest apis or queues. both come with a producing and a consuming side). There are many reasons where that makes sense (e.g. both ms have to evolve the shared storage schema in different directions) but I would not do it out of the box every time like the author implies.

wackget 5y ago

Am I the only one who thinks the initial PHP example is just fine? Seriously, you're claiming to "solve" one "problem" by building an entire new system which is inevitably massively more complex and difficult to manage than the "problem" you're trying to solve. Then again, I don't work in enterprise-level environments but to be honest if this is what it's like, I'm glad I don't.

baq 5y ago
If it’s fine, you can consider yourself lucky. Authentication and authorization complexity is IME squarely proportional to system and organization size due to network effects inside them. At some point it becomes a significant subsystem in itself and contrary to belief of some it becomes a core business problem, not a checkbox to tick off.
Liuser 5y ago
Works fine for 1 application, but what about for thousands of services with many teams? Everything is difficult with scale. We can’t expect every service owner to implement authz correctly, but if we can expose and build tools that help standardize and abstract as much as possible the difficulties of authz then service owners can focus their energy on other things.

cyberpunk 5y ago

Which is why I wont be able to find true love and I’ll die alone. I’ll die alone, without ever knowing it’s my birthday… [0] 0: https://youtu.be/y8OnoxKotPQ https://youtu.be/y8OnoxKotPQ

tored 5y ago

To handle direct database read by multiple micro services you can create views for the different type of authorization checks you need to do. If schema need to change you just update the view.

damethos 5y ago

Author here. First of all thank you for making this article appear in the HN frontpage. I read some interesting comments and approaches but I feel that a piece is always missing (or maybe I did not understood). The piece of how the authorization fetches the necessary application data it needs in order to decide what to do. If you do not need this piece then you can get really creative on how to solve authorization and use an approach that fits best to the needs of your system. But if you do, then I would love to hear more details about this part.

ogazitt 5y ago
Great article! Disclaimer: I'm a co-founder of Aserto [0], where we're building a platform for API / microservices authorization. I couldn't agree more that the question of how to get the data to the policy decision point is one of the most interesting and hardest challenges for this scenario. You don't want to replicate the entire world in both your application's data store and your authorization system. But you also want to follow the principle of separation of concerns as much as practical. There may be scenarios where your authorization system has to make calls to an external system, but that can cause availability and latency concerns. Ideally the decision engine has all the data it needs to make an authorization decision, without having to query another system. For filtering scenarios that involve returning too much data to the client (which the client would need to filter locally), you could also imagine the authorization system doing a "partial evaluation" and return you an AST which you can walk and attach as "where clauses" to your query. Here's an interesting read on how to do this with the OPA decision engine. [1] [0] https://www.aserto.com https://www.aserto.com [1] https://blog.openpolicyagent.org/partial-evaluation-162750eaf422 https://blog.openpolicyagent.org/partial-evaluation-162750ea...

nycdotnet 5y ago

An interesting and well written article. I appreciated that they got into horizontal trimming aka field trimming, but vertical trimming like “this person can see all things for all objects except those with property X==1” is a whole separate issue with significant performance issues, particularly around list endpoints. It’s hard to make a one size fits all solution here because sometimes the perf issue is on the frontend (which items can they see) and sometimes on the back end (now for a fragmented set of entities, fetch and return the appropriate information)

raffraffraff 5y ago

Nit: full-proof is an egg-corn. It's fool-proof.

bigbluedots 5y ago

I know this is a space for entrepreneurs, bit it is a little bit annoying to constantly see folks jumping out of the woodwork with "you should try my product!!!!" whenever there is something semi relevant posted

danielovichdk 5y ago

I don't understand why this is considered a bigger challenge than any other relation between small services. If two services is chatty, they should be merged. This can be on several levels, data being one level. Authorization services should not be chatty with other services. And why would they since you ask for claims upon an authentication request. Yes, I meant authentication. And I believe an authorization service is something that has been solved for a long time. It doesn't have other traits than any other services you must collaborate with, that migh be your mistake to look at it like so. The authorization service will give you the claims for the user and, each service will dictate whether the claims are valid and sufficient within the service boundary. Don't look at it ad a special kind of service, because it's really not.

ranguna 5y ago
> If two services is chatty, they should be merged. Welp, I guess I'll just merge with stripe then, thanks for the tip!

justinjlynn 5y ago

I've never understood why x.509 authorisation certificates aren't more widely used for this. They're off-line, self sufficiently asserted in the connection context, stacking, are unopinionated about application semantics in terms of authorisation rules/grants/restrictions, have well tested infrastructure for parsing and validation, and can use ocsp stapling for validity, and ct logs for audit. They're used in CERN VOMS, etc. and seem like a great fit for distributed systems doing authorisation but they don't seem widely known or used.

mozey 5y ago
Because it's not so easy to setup and manage? Maybe it will become more popular with tools like https://github.com/gravitational/teleport https://github.com/gravitational/teleport
- justinjlynn 4y ago
  That's true. Honestly, it's probably almost entirely down to the fact that the openssl cli 'Swiss army knife' tool doesn't support them purposefully.
deleted 5y ago
[deleted]

h1fra 5y ago

I always wonder how centralised permissions works with listing endpoints. For accessing one resource that's fine, a cached call to any k/v store would work. But when you want to list every items for a resource in a table that contains millions of rows it starts to be more difficult. Without a JOIN you either need to do a costly WHERE IN or filter after the fetch that can results in scanning everything for nothing. Is there any blog post on that?