I've implemented microservice authorization using opa and serverless in AWS. Custom authrorizer is the location where I decode a JWT token and verify authorization.
The explanation of how it ties in with data is vague. Say I have a database with all of my pets and their owners in it. Doesn't make sense to do this via http request because most authorization requires a database call if it's not something simple stored in the jwt and the only way I see this working is if we send it a list of owners in the request. However, it seems nice for microservices without network roundtrips.
Then your pets and their owners data is fetched and then cached in memory inside the AuthZ agent. The data that OPA use to make authorization decisions can be any business-related data
We are awlays speaking about Authorization for a single resource, Get Employees/123 Update Employees/123, what about Get List Employees or search operation... how this pattern will act ? Thanks
so technically if I want to bind a few billions of users who can edit this post, I have to add them manually to OPA rule dataset to bind it? So from server we send the current user id and OPA check if passed id is among manually bound billions of ids? It will take dozens of years to fill them manually, or insane of traffic to pass on each request
There must be some kind of business logic about it? Let's say that few billions of users is the members of a group that contains the post, then a custom function is_member_of_group(post_id) will do the job. It makes no sense if that few billions of users are completely arbitrary
I am question , when the authorization of each user changed in example , the role of user in group is exprised or new policy of business was changed the permissions , how you resolve the changed in OPA and updating the permissions in JWT payload or other shared memories of authorizaton server. I assume in case realtime in hight rate request of client
15:09 There is a blue part called "Updater" that periodically update the policies and data, but in the presentation they did not talk about how to manage inconsistency when caching policies and data inside the Authz agent, i guess we need on-demand cache invalidation mechanism for consistency here
Authorization applies to resource access as well as information access. Does OPA cover situations where role R is permitted to access resource X except for the F field that the service sends in its response? One answer would be to author the service to separate out such "sensitive" information as a resource .. but that may not always be possible, especially retrospectively. For example, a customer support app may want to retrieve a customer's information but not have permission to read bank account number. If the "customer info" service clubs all of that .. we'll want to restrict the response to a subset.
Great talk! Just a few questions what stops an application posing itself as a different app name? What verifies a user is a certain user and not another user, example just a token that is validated before the requests gets to the service?
You can be flexible with different kind of authorization. Some policies can be cached and stale/inconsistent data are acceptable, some other important policies that can't afford any inconsistency can have different caching mechanism
![CNCF [Cloud Native Computing Foundation]](http://yt3.ggpht.com/txe66EjpkDQQlx_4jDV0yA0PPsww0rqQrFhMpDqagLWN2-EUBBO65IuIyy5tEFVmpI4_RRduzXc=s48-c-k-c0x00ffffff-no-rj)
And I'm here trying to solve the Authorization problem by myself as a undergraduate! This is a whole different story.
I've implemented microservice authorization using opa and serverless in AWS. Custom authrorizer is the location where I decode a JWT token and verify authorization.
You are genius Jason
The explanation of how it ties in with data is vague. Say I have a database with all of my pets and their owners in it. Doesn't make sense to do this via http request because most authorization requires a database call if it's not something simple stored in the jwt and the only way I see this working is if we send it a list of owners in the request. However, it seems nice for microservices without network roundtrips.
Then your pets and their owners data is fetched and then cached in memory inside the AuthZ agent. The data that OPA use to make authorization decisions can be any business-related data
We are awlays speaking about Authorization for a single resource, Get Employees/123 Update Employees/123, what about Get List Employees or search operation... how this pattern will act ?
Thanks
so technically if I want to bind a few billions of users who can edit this post, I have to add them manually to OPA rule dataset to bind it? So from server we send the current user id and OPA check if passed id is among manually bound billions of ids? It will take dozens of years to fill them manually, or insane of traffic to pass on each request
There must be some kind of business logic about it? Let's say that few billions of users is the members of a group that contains the post, then a custom function is_member_of_group(post_id) will do the job. It makes no sense if that few billions of users are completely arbitrary
I am question , when the authorization of each user changed in example , the role of user in group is exprised or new policy of business was changed the permissions , how you resolve the changed in OPA and updating the permissions in JWT payload or other shared memories of authorizaton server. I assume in case realtime in hight rate request of client
The jwt payload should ideally not carry any authorization information
15:09 There is a blue part called "Updater" that periodically update the policies and data, but in the presentation they did not talk about how to manage inconsistency when caching policies and data inside the Authz agent, i guess we need on-demand cache invalidation mechanism for consistency here
Authorization applies to resource access as well as information access. Does OPA cover situations where role R is permitted to access resource X except for the F field that the service sends in its response? One answer would be to author the service to separate out such "sensitive" information as a resource .. but that may not always be possible, especially retrospectively. For example, a customer support app may want to retrieve a customer's information but not have permission to read bank account number. If the "customer info" service clubs all of that .. we'll want to restrict the response to a subset.
One solution is to separate services altogether, If you separate services for different roles this could solve it.
Great talk! Just a few questions what stops an application posing itself as a different app name? What verifies a user is a certain user and not another user, example just a token that is validated before the requests gets to the service?
All that comes in authentication
Signed JWT
is it open sourced yet? Nice stuff
How do you scale when you have 100s of millions of users ? Can the auth agent store so much of data in memory ?
database sharding can be a great help on that
@@irasychan how cant update the authorization of regular user
You can be flexible with different kind of authorization. Some policies can be cached and stale/inconsistent data are acceptable, some other important policies that can't afford any inconsistency can have different caching mechanism
Is this similar to what Istio does?
Perhaps when Istio is able to run across legacy apps and microservices