At first glance, authorization seems easier than authentication. After all, with authentication you have to worry about user onboarding, social auth, MFA, password resets, and more. Authorization starts from the simple question of: “Can this user see this resource?”
Unfortunately, that’s where the simplicity ends.
Today we’re excited to launch our new AuthZ service and most importantly to demonstrate how our approach is fundamentally simpler for teams to adopt and scale.
Most authorization products require you to make hard either-or decisions between Role-based and Relationship-based Access Controls up front. While that distinction is important, it’s not how the real world works. Successful applications spring into being in their final form. They ship. They iterate. They grow. Locking teams into specific solution paths at the start creates a perpetual re-architecting cycle.
When we designed our AuthZ service, we started from the premise that most applications would start with a simple Role-based (RBAC) approach for managing access. In the earliest stages of our app, this makes sense. We can draw boundaries around being an Admin vs a regular user. As the application grows, we realize that users should have access to their data but not others’ so we add relationships like “ownership” and “parent-child” to inherit access across Relationships (ReBAC). Finally, we get into access decisions based on being part of a team, being in the US versus the EU, or other attributes (ABAC) of the user or target resource.
With our AuthZ approach, you create the Resource Types in the system and - by default - we give you the Owner relationship immediately. You can optionally remove it or create more but the scaffolding is available from the start. When you move into Roles and setting their access, you can start with your global, cross-cutting Roles or use the Owner relationship to create more fine-grained access. Wherever you start, you can grow your policies along with your app with minimal rethinking along the way.
Authorization doesn’t exist in a vacuum. In fact, when we design authorization into our application, odds are it represents underlying business processes, organizational boundaries, and even compliance requirements. Therefore, every time we “design” authorization, we’re really just adapting it to our current application and use cases so we’re really re-re-redesigning authorization for the 37th time and we’ll have to do it again next sprint.
With our AuthZ approach, you can abstract the roles, relationships, and access rules out of your app into a shared system that every app can leverage. The process comes down to four steps:
You create the Resource Types and build their Relationships
You create the Roles and define their Access
You tell us about the Resources as you create or update them
You check for Access
For example, you tell us “Luke is an Admin” and we’ll resolve the implications for any and all Resources.
The most important aspect is these updates don’t have to come exclusively from your app. If your membership is managed in another app, your Ops team uses SlackOps, or you have batch jobs running out of band, access control changes are reflected immediately and reusable for all.
When we get deeper into authorization, we realize that most access controls are based only on roles, relationships, and rules but that ignores entire classes of attacks. If someone steals your credentials and attempts an action, how does an authorization system confirm that it is you and grants access?
With the Pangea AuthZ approach, that’s our vision. With a unified security platform, you have an entire toolbox of components to mix and match to meet your security needs. With services like AuthN, IP Intel, Embargo, or even File Intel, we can analyze the context of the user, the request, and even the resource so your Security Team can adapt your security posture across every app at one time. We envision a time where building rules like this doesn’t require re-architecting your app, negotiating with numerous vendors, or even changing a line of code:
“Laura only has access to documents after using a strong authentication factor from a known-safe IP address and only if the documents are not malicious.”
Now we’ve protected our user, our documents, and our organization better without changing the downstream applications. Further - like any Pangea service - AuthZ is backed by our Secure Audit Log so the Security Team can confirm when Leia did or did not get access. Overall, your team can build a more secure but flexible solution from end to end.
To get started with Pangea AuthZ, our AuthZ Overview page will walk you through the basics and help you get a simple schema started. It will start you with a simple Role-based approach letting you grow into introducing Relationships and building Access rules based on each.
Like all services, we have detailed API docs and even Postman Collections to let you explore, play, and understand exactly how things fit together.
Sign up for free to get started and visit us in the Pangea Community for questions, support, or to show off what you’ve built.
Services
Case Studies
Use Cases
Developers
636 Ramona St, Palo Alto, CA 94301
PrivacyTerms of UseYour Privacy ChoicesContact us