DEV Community: Or Weis

Everything You Need to Know about AWS’ Cedar Policy Language

Or Weis — Sun, 02 Jul 2023 10:08:25 +0000

If you're working with AWS, or in general with application level permissions, you'll want to get familiar with Cedar, a new policy-as-code language developed by AWS. It's a game-changer for policy management and access control, introducing a structured and scalable way to manage permissions. Here's a compilation of key articles that delve into Cedar's capabilities and potential:

AWS Cedar: A Game Changer for IAM

This article provides a comprehensive overview of Cedar and why it's a significant advancement for IAM management. It discusses how Cedar simplifies policy creation, enhances scalability, and improves security, all while remaining open-source and easy to adopt. This is a must-read for anyone wanting to grasp the basics of Cedar.
Cedar and Role-Based Access Control (RBAC)

Learn about the intersection of Cedar and RBAC in this article. It covers how Cedar takes RBAC a step further, allowing for fine-grained, context-aware permission control. The piece also explores Cedar's role in a range of situations, from simple access control to complex use cases.
Authorization and Cedar: A New Way to Manage Permissions Part I

This deep dive into Cedar's role in managing permissions is the first of a two-part series. It discusses how Cedar offers a more efficient and secure way to manage permissions, with a focus on the basics of writing Cedar policies and using Cedar to enhance authorization.
Scaling Authorization with Cedar and Opal

This post details how Cedar and Opal can work together to create scalable, robust authorization systems. It covers the benefits of using these tools together, including the increased flexibility, improved security, and better scalability that result from their synergy.
Cedar: Questions and Answers

If you have questions about Cedar, this article has answers. From the basics of what Cedar is and how it works, to more complex inquiries about specific use cases and compatibility, this comprehensive Q&A is a helpful resource for understanding Cedar.
OPA vs Cedar: A Comparative Analysis

This article provides a comparative analysis between Cedar and Open Policy Agent (OPA), another popular open-source policy-as-code framework. It outlines their respective strengths and weaknesses, and offers insights into why you might choose one over the other.
Cedar Awesome: A Community Project

This GitHub repository is a curated list of resources, articles, tools, and other materials related to Cedar. It's a community project designed to promote the understanding and usage of Cedar. Whether you're a beginner or an advanced user, you'll find something helpful here.

Cedar is an innovative tool that significantly simplifies and enhances IAM management on AWS. Its policy-as-code language provides unprecedented control, flexibility, and scalability. Take the time to explore these resources and understand how you can leverage Cedar's capabilities in your AWS environment.

How to choose an Authorization Service?

Or Weis — Wed, 04 Jan 2023 15:04:44 +0000

Every developer building an application catering to more than one user has encountered the challenge of authorization (aka permissions) - covering standard features like RBAC, ABAC, ReBAC, multitenancy, policy editing, invites, approval flows, and much more. But how do you pick the best service for it?

Before we start breaking the decision process of picking an authorization service, let's, just for the sake of clarity, define what it is first –

What is Authorization as a Service

Authorization as a service (or better-named 'Permissions as a Service' to differentiate from 'Authentication as a Service') enables software developers to build applications that can request and receive permissions to access certain resources or perform certain actions on behalf of an end-user. These permissions are typically granted by the end users themselves.

By using a 'Permissions as a Service' provider, developers can focus on building their application's core functionality rather than spending time and resources building and maintaining their own authorization and permission management systems.

Don't Confuse with Authentication

Every developer, when presented with the question: "Do you know the difference between Authentication and Authorization"? Will undoubtedly reply: "Of course!" In reality, you'd be surprised how often they confuse the two.

Authorization as a service really (and I mean really) shouldn't be confused with authentication as a service; which deals with verifying identities (as opposed to checking what they can do or not, once verified).

Some authentication services come with role and/or user management - making you think they include permissions, but these always just translate to claims in your JWT, which still require you to write code to enforce alongside more data points (e.g., billing status, anomaly detection); or worse - they translate into a simple API you query in their cloud - both killing your application's performance with latency and limiting your ability to upgrade to more complex policies (e.g., moving from RBAC to ABAC).

Why Should You Use an Authorization Service

Building permissions as a service is at a critical junction of requiring advanced knowledge in cryptography, cybersecurity, the intricacies of policy models (e.g., RBAC, ABAC), and high-performance real-time distributed systems - all while not being unique to any product.

Authorization requirements have a tendency to grow exponentially with the application; starting easy at first (e.g., Admin / Not admin - hardcoded into the app) but quickly becoming complex with the various requirements from customers, security, compliance, and 3rd party integrations. With new requirements often leading to a full refactor every 3-6 months.

The bottom line is that you should use an authorization service to avoid wasting time reinventing the wheel and avoid making mistakes that can easily translate into vulnerabilities or critical performance issues.

The Key Factors for Choosing an Authorization Service

Compatibility:

Let's face it, you probably already have something in place (even if it's just a single DB table with a user role column). So make sure that the solution is compatible with your existing systems and infrastructure. This includes compatibility with your cloud environment, programming language, and data sources.

In addition, you should make sure that the transition to the new solution can be a gradual and fast one (or at least gradual). Gradual means the ability to run the new solution side by side with your existing one and test it behaves as you expect.

Best Practices:

Anyone can build a service that just returns a list of roles (and many developers do at some point or another in their careers) - but without the best practices baked into the solution, maintaining it, and ultimately refactoring or replacing it would be painstaking and time-consuming.

Policy as Code, event-driven updates, Gitops, control-plane back office, and customer-facing experiences are some of the best practices you will need and really shouldn't compromise on.

Latency and locality:

The average microservice-based application triggers three authorization queries per request. If each takes more than 50-100ms, the performance of your application is basically dead before it even starts to handle its own core logic. Latency across cloud services is basically unavoidable (the service provider might be able to reduce it somewhat but not remove it altogether - especially under heavy workload scenarios).\
Hence it is best to avoid authorization services that provide only remote querying options and that haven't taken latency into account.

Policy Model Support:

As your application evolves to meet new demands, so will your authorization layer - so while everyone often starts with Admin/Not-admin, RBAC, ABAC, ReBAC, and variants of them are most likely in your app's future. Different solutions would support different models and varying levels.

For example, Google-Zanzibar-inspired solutions are a great way to implement ReBAC but are often impossible to implement or impractical for ABAC.

Scalability:

Consider the scalability of the solution. If you expect your user base to grow significantly over time, you'll want a solution that can handle the increased load and complexity (e.g., of policy or application structure).

Security and compliance:

Security is always an important consideration, especially regarding access control. When picking a service provider, you should aim for one that has cybersecurity as part of its DNA, building with security by design (and not adding it as layers later). You should ask your provider how they intend to work with your sensitive data for authorization without increasing your attack surface and risk of data leakage.

Ease of use:

Choose a solution that is easy to use and set up. This will make it easier for you to manage permissions and reduce the risk of errors. Remember that this tool isn't going to be just for your own use - your fellow stakeholders (e.g., product managers, security teams, compliance, support, sales, ...) will need to work with this as well. The better you can delegate usage to them, the less of a bottleneck you'd have to be. Prefer solutions that provide user interfaces, as opposed to just APIs and infrastructure.

Support:

Make sure the solution has good customer support in case you have any issues or questions.\
I'd recommend taking their support for a spin, asking a question in the solutions community or support forum, seeing how quickly you get a response; or at least glance at how quickly other people's questions get answered.

TL;DR

Authorization as a Service, also known as permissions as a service, enables developers to build applications that can securely gate access to certain resources or perform certain actions on behalf of an end-user. Using an authorization service allows developers to focus on building their core application functionality rather than spending time and resources building and maintaining infrastructure, APIs, and human interfaces that aren't unique to any application. When choosing an authorization service, compatibility with existing systems and infrastructure, best practices, latency and locality, scalability, and cost should all be considered. It is important to use an authorization service to avoid reinventing the wheel and to avoid mistakes that can lead to vulnerabilities or performance issues.

What is Policy as Code?

Or Weis — Thu, 15 Dec 2022 17:35:42 +0000

TL;DR

⁠Policy as code is a concept that refers to the practice of defining and managing policies using code. This allows policies to be managed and enforced using the same tools and processes that are used for managing and deploying software.

The Benefits of Policy as Code

There are many benefits to having policy as code, including improved consistency, accuracy, and traceability.

Defining policies using code provides organizations with the ability to ensure policies are consistently enforced across different systems and environments, which can help prevent policy violations and reduce the risk of unauthorized access to sensitive data or systems.

Policy as code allows them to be more easily managed and updated. When managed as code, policies can be managed using the same tools and processes used to manage and deploy software. This makes it easier to track changes to policies over time, roll back changes if necessary, and in general, enjoy the well-thought-through best practices of the code world (e.g., GitOps).

Now that we have gone over the benefits of having policy as code let’s talk about what this would look like in practice!

Examples of Policy as Code

One example of a policy as code implementation is Rego - the language used by Open Policy Agent (OPA). Rego is a high-level declarative language that is designed specifically for defining and managing policies. It is a Prolog / Datalog derivative language, and it allows policies to be defined using simple sets of rules, which can be handled recursively by the OPA engine.

Here is a super simple example of a policy written in Rego:

package example

import input

default allow = false

allow {
  input.user.role == "admin"
  input.resource.category == "sensitive"
}

In this example, the policy specifies that a user is only allowed to access a resource if they have the "admin" role and the resource is in the "sensitive" category. The policy is defined using simple, declarative statements, and it can be easily understood and modified by anyone familiar with the language.

That being said, Rego isn’t your run-of-the-mill programming language like Python or Java and can have somewhat of a steep learning curve. To learn more, check out these articles about implementing RBAC with OPA and Implementing ABAC with OPA.

OPA’s Rego is just one example of a policy-as-code language. Many other such languages exist (Such as Google Zanzibar Schemas, Cedar, OSO, and many more), with each of them having its own supporting tools. At the end of the day, picking the correct language and tools will depend on the specific needs and requirements of what you’re building.

Policy as low/no code

While policy-as-code should be managed in a code repository, that doesn’t mean it should be authored as pure code. By simplifying policy creation, we can make our work as developers easier, free ourselves from becoming bottlenecks, and empower other critical stakeholders (e.g., product managers, security, compliance, support, professional services, and sales) to participate in the policy creation process.

The way to achieve this is through using solutions that provide low-code interfaces that generate policy code right into a Git repository (Like Permit.io 😉). This allows developers to** test, benchmark, and even code review the generated code** - all while maintaining the ability to add more code on their own for the more advanced cases.

Using low-code policy interfaces also reduces dependence on a single policy engine and allows for embracing a more polyglot dynamic approach to software (as you would anyway - it's all about using the right tool for the right job).

Want to learn more about authorization best practices? Join our Slack community, where there are hundreds of devs building and discussing authorization.

The developer’s guide to IAM buzzwords

Or Weis — Tue, 13 Dec 2022 15:52:06 +0000

Identity and access management (IAM) is the processes and technologies used to manage the identities of users and the access they have to different systems and resources. IAM can be divided into three main parts - authentication (verifying a user's identity), authorization (granting or denying access to resources), and identity management (creating, updating, and deleting identity records and associated information). IAM systems are often used to improve security, simplify access management, and reduce the risk of unauthorized access to sensitive data or systems.

IAM works like a waterfall:

Information flows from the organization side to products used by the organization, starting at the identity provider to authentication at a product’s gateway, and finally to authorization within the product itself.

Let’s Zoom in on each of these —

Identity management

Identity management solutions help organizations to securely manage the identities of their users and control access to their applications and resources.
Identity providers and the identity management process, in general, act as the main source of truth for Authentication and Authorization.

Leading Identity management services include:
Okta, Microsoft Azure Active Directory, OneLogin, Ping Identity, Google Identity Platform

Key Identity management Buzzwords:

Single sign-on (SSO): A system that allows users to log in to multiple applications using a single set of credentials. This can make it easier for users to access the resources they need, and it can also reduce the number of passwords that need to be managed and remembered.
Identity provider (IdP): An identity provider is a service that manages the identities of users and provides authentication services. This might be a separate service, or it might be integrated into other systems.
Federation: Refers to the process of linking different identity systems so that users can use the same credentials to access multiple systems. This can be useful in situations where multiple systems need to share user information, but each system has its own authentication mechanism.
SAML (Security Assertion Markup Language): A standard for securely exchanging authentication and authorization data between different systems. It is often used in enterprise environments to enable single sign-on across multiple applications.
SAML is one of the main protocols authentication services would connect to Identity providers.
LDAP (Lightweight Directory Access Protocol): A protocol for accessing and managing directory information over a network. It is often used for authentication and authorization in enterprise environments.

Authentication

The process of verifying a user's identity. This is typically done by requiring the user to provide some kind of credentials, such as a username and password, a fingerprint, or a facial recognition scan.

Leading authentication services include:
Auth0, AWS Cognito, SuperTokens, FusionAuth, Magic.link, Stych, Descope.

Key Authentication Buzzwords:

OAuth: OAuth is an open standard for authorization (but de-facto powers a lot of authentication) that allows users to securely access resources on one site using the credentials of another site. OAuth is often used to allow users to log in to third-party applications using their Google, Facebook, or other social media accounts.
OpenID Connect: OpenID Connect is a protocol that builds on top of OAuth to provide authentication as well as authorization. It allows users to securely log in to a web application using their existing credentials from another site.
Multi-factor authentication (MFA): Multi-factor authentication is a security system that requires users to provide multiple pieces of evidence to prove their identity. This might include something they know (like a password), something they have (like a security token), and something they are (like a biometric factor like a fingerprint or a facial recognition scan).
JSON Web Tokens (JWTs): JWTs are a compact, URL-safe way of representing claims to be transferred between two parties. They are often used for authorization and can be signed using a secret key or a public/private key pair. It is the main connection point between authentication and authorization solutions.
Passwordless authentication: a method of authentication that does not require users to enter a password in order to access a system or service. Instead, users are authenticated using other methods, such as a biometric factor (like a fingerprint or facial recognition), a security token, or a one-time code sent to their email or mobile device. It is becoming increasingly popular as a way to improve security and user experience (by reducing dependency on stupid passwords 😅)
WebAuthn: is a web standard that defines an API for performing authentication using various authentication methods. This includes methods like biometric authentication (using a fingerprint or facial recognition), security keys (using a hardware token), and other methods that are more secure and user-friendly than traditional password-based authentication.

Authorization (aka Permissions)

The process of granting or denying access to resources based on a user's identity and the permissions that have been assigned to them. This is typically done by comparing the user's credentials against a set of rules or policies to determine what they are allowed to access.

Leading Authorization services include:
⁠Permit.io, AuthZed, Ory Keto, Styra DAS

Key Authorization Buzzwords:

Role-based access control (RBAC): The bread and butter of access control; almost every product developer gets here - thanks to its simplicity, it has become quite popular and common.
Role-based access control is a method of access control that assigns permissions to users based on their role within an organization. For example, an administrator might have more access than a regular user.
Attribute-based access control (ABAC) is a method that uses attributes (or "properties" of a user or resource) to determine whether a user is authorized to access a particular resource. This is in contrast to other forms of access control, such as role-based access control (RBAC) or discretionary access control (DAC), which use fixed roles or permissions to determine access. ABAC allows for more fine-grained and flexible access control, as it allows permissions to be based on multiple attributes and dynamically evaluated. For example, a user might be granted access to a particular resource if they have a certain role and are accessing the resource from a specific location at a specific time of day.
Relationship-based access control (ReBAC) is a method of access control that takes into account the relationships between different users and resources when determining access permissions. This is in contrast to (RBAC), which assigns permissions based on a user's role within an organization, or discretionary access control (DAC), which assigns permissions based on the user's individual permissions.
ReBAC is more powerful than RBAC but can often be more limited when compared to ABAC.
ReBAC is perfect for describing groups, hierarchies, and forms of cascading or nested relationships. The most classic example is file systems, where access to a folder implicitly grants access to anything nested under it.
Policy as code: the practice of defining and managing access-control policies using code. This allows policies to be managed and enforced using the same tools and processes that are used for managing and deploying software. This makes it easier to track changes to policies over time, to roll back changes if necessary, and in general, to enjoy the well-thought-through best practices of the world of code - e.g., Gitops.
OPA (Open Policy Agent): A popular open-source (CNCF project) policy engine that enables developers to externalize and manage their policies in a uniform and predictable way. OPA provides a high-level declarative language (Rego) for specifying policies, as well as an engine for enforcing those policies at runtime.
OPAL (Open Policy Administration Layer) - is an open-source project to manage multiple instances of OPA in a real-time, event-driven fashion, delivering the policy and data each agent needs (and only those it needs).
Google Zanzibar: a white paper published by Google describing how they use ReBAC via a graph-based system to manage permissions at scale for products with high volume usages (more than tens of million users) such as Drive and Youtube. The whitepaper, which didn’t include the source code - unleashed a wave of clones, none of which to date has actually fully implemented the offering.

Still confused? Want to learn more about IAM? Join our Slack community, where there are hundreds of devs building and discussing IAM.

Low-code ABAC: a prerequisite for the Future

Or Weis — Thu, 29 Sep 2022 15:28:51 +0000

Today we are excited to share an important milestone in Permit’s product roadmap, and perhaps more than that - a key milestone in how we think about access control: Low-code Attribute Based Access Control (ABAC).

As applications are becoming more complex, their policies have to follow suit.
Policies for billing (e.g. "only users who paid for a feature can use it"), location, time, trust level, quotas, anomaly, fraud, and risk profiles are becoming basic requirements, with these examples just scratching the surface, as even greater complexity awaits just around the corner (think AI agents, Web3, DeFi, IoT, metaverse assets, …).

Before Permit.io and the concept of permissions-as-a-service, developers were forced to build and rebuild authorization over and over again to meet the constant stream of requirements coming from customers and fellow stakeholders (e.g. product, security, compliance, support). With Permit’s RBAC solution, policy-as-code became as easy as checking a checkbox - generating the needed code for you, wrapping it nicely into Git, and API / UI interfaces.

We had ABAC in mind from day one, and we supported it via direct code and Gitops. Still, to have complex policies (e.g. ABAC), users had to write code. We recognized that as long as policies remain accessible only through complex R&D work and steep learning curves (e.g. writing Rego code), developers would remain bottlenecks. This results in locking the other stakeholders out of the conversation, and leaving customers thirsty for their modicum of freedom within products- a thirst constantly manifesting as an unending stream of feature requests.

We knew that when it comes to ABAC, low-code is a must. We can only meet these ever-increasing challenges if we make access controls inclusive and empowering for everyone.

The secret sauce behind this launch is the understanding that ABAC should be as simple as RBAC (Role Based Access Control) - ABAC should be as simple as assigning a role. RBAC’s simplicity is why it became the bread and butter of the IAM world.
Working on this problem, we refused to relent until we found an elegant and simple solution. The eureka moment came in the form of breaking down ABAC into several independent yet connected systems, each one simple enough for a non-technical user. These systems enable the most complex patterns while converging back into a single source of truth as code managed in Git.

With concepts like User-Sets and Resource-Sets (aka Condition-Sets), the Permit.io ABAC system allows users to transition from RBAC to ABAC smoothly and use complex attributes and conditions on them as if they are RBAC roles.

With the new ABAC system, developers can customize every little aspect (with API or directly with code), but more importantly - they don’t have to - as the low-code interfaces are both simple and powerful enough to enable the entire team, including non-developers as well as the customers themselves, to work independently on access-control within the bounds set by developers/owners.

As we launch low-code ABAC support, we are excited about what this means for software and access control, but most importantly, we are excited to see what you build with it.

Ready to get started with ABAC? Read the docs here, and simply try it out directly

Got questions? Join our Slack community, or chat with us on Zoom.

Realtime channels ⚡- RPC, PUB/SUB at scale

Or Weis — Tue, 23 Mar 2021 14:20:27 +0000

As modern software is exploding (especially in the cloud and at the edge) the need to deliver realtime data, updates, and events at scale across deployed instances is ever increasing.
A challenge we had to solve for our own fullstack authorization as a service solution (authorizon.com)
That's why we've created ⚡ FastAPI-websocket-RPC and 🗞️ FastAPI-websocket-PubSub.

Why Websocket-RPC ?

Often you'd like to trigger events and/or access code on the client side (and not just on the server). Explicitly exposed RPC methods are the easiest way to go about it.
Each side (both client and server) can expose Python methods like this:

class RpcCalculator(RpcMethodsBase):
    async def add(self, a, b):
        return a + b

And the other-side can call them (and wait for a response with a return value) like this:

response = await channel.other.add(a=1,b=2)
print(response.result) # 3

Pub/Sub

Similarly Pub/Sub is the easiest way to have different services share updates.
Once a server is up:

app = FastAPI() 
endpoint = PubSubEndpoint()
endpoint.register_route(app, "/pubsub")

clients can then subscribe

async with PubSubClient(server_uri="ws://localhost/pubsub") as client:
# Callback to be called upon event being published on server
async def on_event(data):
    print("We got an event! with data- ", data)
# Subscribe for the event 
client.subscribe("my_event_topic", on_event)

and publish

async with PubSubClient(server_uri="ws://localhost/pubsub") as client:
    endpoint.publish(["my_event_topic"], data=["my", "data", 1])

With ease 😇

Why Realtime / Websocket?

Polling systems are the worst - constantly creating overhead, and are always delayed and suffering from consistency issues. Websockets are ideal for traversing the cloud and the internet. Thanks to running on top of an initially outgoing HTTP connection, all the common issues one would face with firewalls and routing for most bi-directional channels are inherently solved. When push comes to shove - software should always push rather than pull 😜.

Why on top of FastAPI

With Python, asyncio, Starlette, and Pydantic at its core, FastAPI provides great performance (still not as good as GO, but comparable/superior to Node.js) and enjoys the dev-speed and maintainability of typed Python. Its dependency injection mechanism allows our RPC and PubSub to easily enjoy all the benefits of the underlying HTTP (Such as authorization, cookies, routing) with easy configuration.

Performance

While we haven't created official benchmarks yet, we have successfully run these packages in production with 100s of events per second, per server instance, with no issue. In addition instances can scale horizontally with ease (thanks to the broadcasting mechanism).

Pub/Sub - Why not RabbitMQ, etc. ?

First, RabbitMQ is great - but it's not a cure-all;

FastAPI WS Pub/Sub allows to decouple the backbone Pub/Sub (such as RabbitMQ, Kafka, or Redis) from the API layer - which is more lightweight. Bringing tons of benefits:

Allowing to scale-out the lightweight layer without having to scale-out the backbone (which is often much more resource intensive)
Being able to work with the native API (e.g. REST, GraphQL) in tandem (being part of the same framework or even process)
Choosing whichever backbone Pub/Sub channel you'd like, and being able to easily switch (no lock-in).
Code level control - this solution embeds into your Python code, you don't have to look at it as a blackbox (unless you want to).

Bottomline

Realtime data propagation is becoming a common task, and we hope these open-source packages would make it easier for everyone to accomplish.
Take them for a spin and tell us what you think