.@dschenkelman's chat with @juanrossi, a Senior Platform Security Manager at @Mercadolibre. Join us to know more about their Authorization challenges and how they tackled them.
#Authorization and #Authentication are too critical to have everyone learning and implementing them from scratch. With more tens of thousands of employees, @Mercadolibre needed to create a solution that is easy to use and can be implemented in any language and tech stack
They also needed to solve for an important problem that touches on #AuthN and #AuthN: how to handle delegation of permissions, where a user can act on behalf of another user.
They have thousands of applications.
Having each service had to do it's own authorization raised some issues:
* requires maintaining every implementation to prevent vulnerabilities
* improvements & new features rely on modifying implementations by many teams
* visibility is hard
A centralized solution that is standardized within the company & shared by multiple systems alleviates many of these issues
* Create an token and send it to applications.
* Applications request decision from the policy agent.
Downsides: higher latency, single point of failure
> Downsides: higher latency, single point of failure
Bundling the AuthZ agent into sidecars improves latency and performance.
Side-note: This article from the @netflix tech blog might be interesting to people following along:
AuthZ question and logic "if user has this permission, allow otherwise deny" implemented in #Rego and evaluated on a framework based on #OPA
Rego allowed them writing #AuthZ decisions and use regex, loops, etc.. It is a complex language with a learning curve.
Benefit of #Rego and #OPA:
* Framework is pretty good on the optimization side where policies are indexes
* policies evaluated in microseconds
Because of it's complexity and steep learning curve, asking the whole company (thousands of employees) to learn #Rego was not practical
They needed to create abstractions that make it as simple as possible to implement #AuthZ
Q: How do you know if a team is using an #AuthZ anti-pattern
A:
* Hard to police
* Educate. New system in place for only a few months, work is still underway to document and answer most questions
* Push people away from writing their own #Rego solution
* Consistent approach
They have policies stored on S3, sidecars pull the information every minute, and update in memory if changed.
Checks prevents people from deploying policies to production without approval.
While building their solutions, they focused on having a generic solution that can handle permissions and can answer any #Authorization question.
Resilience and low-latency were also important
Pragmatism is important.
They did not focus on having the most performant and scalable solution from day one.
* test hypothesis early
* build a system that performs correctly
* iterate from there
That was it!
Recording of the discussion will be up in the next few days
Thanks to @juanrossi from @MercadoLibre for joining us and sharing his insight & knowledge into #AuthZAtScale, the challenges he and his team are facing, and his thoughts on how they are approaching them
If you didn't manage to catch the chat yesterday, fear not! The recording is now up. You can find it here 👇
3/ 0️⃣ Introduction
Zanzibar is a "Relationship based access control" (ReBAC) authorization system, i.e.: a user has access to an object if it has a particular relation to it.
Zanzibar stores (object, relation, user) "tuples" with data about these relations.
3/ You'd: 1. Sign up for a subscription 2. Configure who has access to what 3. Pick an SDK for your favorite language/tool 4. (optionally) Feed your authZ data from existing sources into #sandcastle
That's the ideal future. At this point you'd have AuthZ for your app 🤯
We'll go over what is currently being addressed and what the gaps are👇
2/
As we've mentioned before, solving #fgaatscale requires:
1️⃣ Permission modelling flexibility
2️⃣ Auditing capabilities
3️⃣ Correctness: no invalid permissions are granted
4️⃣ Low Latency
5️⃣ High availability
3/ Solving #fgaatscale is becoming a need because:
☝️ Users expect collaboration features in most products they used, and that requires FGA
✌️ Increasing privacy and compliance regulations require companies in different verticals to restrict access as much as possible
3/ Like github, @googledrive has B2C and B2B models. However, @googledrive's sharing model is the same for B2C and B2B. The difference is who you can share files with.
In this thread explore we'll the problems of authorization at scale using a real world, well known example
2/ This is a key part of product development, especially when building infrastructure. We want to understand what our customers will eventually build with our service.