DEV Community: OdedBD

Load external data into OPA: The Good, The Bad, and The Ugly

OdedBD — Mon, 04 Apr 2022 14:48:28 +0000

There are several ways to create a data fetching mechanism for OPA - each of them has its pros and cons. To make sense of these different methods, I've decided to create this guide that will help you figure out which data fetching method would be best for you, with full knowledge of each method’s ‘good, bad, and ugly’ aspects.

TL;DR -

The methods that we are going to review are:

Including data in JWT tokens
Overload input for OPA within the query
Polling for data using Bundles
Pushing data into OPA using the API
Pulling data using OPA during Policy Evaluation
OPAL (Open Policy Administration Layer)

Before we dive into details, let’s first cover some basics -

What is OPA

Authorization is becoming increasingly complicated - applications are getting bigger and require handling more users than ever before, policies are becoming more complex and dependent on multiple factors (Like a client’s location, time of the action, user roles, and relations to resources).
This is where OPA (Open Policy Agent) comes in - OPA is a great open-source tool that allows us to evaluate complicated policies. It’s fast, part of the CNCF (Which means it adheres to CNCF’s guidelines and standards), and is used for handling permissions in some of the largest companies in the world (e.g. Netflix, Pinterest, and others). You can check out an introduction to OPA here.
⁠

How OPA Works with Data

Managing policies with OPA often requires relevant contextual data - Information about the user, the resource they are trying to access, etc. Without this information, OPA will not be able to make the right decisions when it comes to deciding on policies.
For example - a policy that states “Only paying users can access this feature” requires OPA to have information on:

Who my users are
Which one of them is a paying user, and which isn’t

A policy that states “Users in the application can only access their own photos, or those of their children” requires OPA to know:

Who are the application’s users
Which user is a parent, which user is a child, and which user relates to who
Which photo belongs to each user

Having access to this contextual data is thus critical for OPA to be able to make its decisions.

The bottom-line question is - how can we bring this data into OPA, and which way is the most effective to do so?

The data fetching mechanism: Basic requirements

Before we dive into the different methods of fetching data for OPA, let’s agree on a couple of basic guidelines for how this data fetching mechanism should work:
It's necessary to be able to handle data about policies on a large scale

Because data can come from many sources, thus getting very complex very quickly, we want this mechanism to be as easily manageable as possible.

The data fetching mechanism needs to be operational in real-time (This is a crucial component that will allow us to avoid a “New enemy attack” - a situation where a user with revoked permission can still access sensitive data because the permissions have not been updated in time between the different parts of the system).

It should be easy to maintain because the need for access control is here to stay and is likely to evolve in the future.

Now that we've established some basic requirements, let’s dive into the various data fetching mechanisms we can utilize to solve our issue in the most efficient way.

Let’s dive in!

1. Including data in JWT tokens:

JSON Web Tokens (JWT) allow you to securely transmit signed JSON data between software systems and are usually produced during the authentication process. JWTs can be sent to OPA as inputs thus enabling OPA to make decisions about a Policy query.

For example, this is what a JWT with authorization data looks like:

The first part is the algorithm for the secure signing, and in the middle, we can see the roles and related images for our authorization.

The good:
JWTs are an easy-to-use well-known technology that you probably already utilize in your system (as part of the authentication layer).

The bad:
JWTs have a size limit - not everything can be decoded into a JWT, while it looks OK in the example presented above, if a user has 1000 files the JWT length changes from 239 characters to 20,057 - and that’s considering a simple file name. With the full path, it’s even longer. Additionally, a JWT created during the authentication phase doesn’t include all the necessary information required to make the policy decision - especially if you are using a vendor like Auth0 to authenticate. In addition, storing data in JWTs means we have to refresh the token (read as login/logout) every time we want to update the data.

The ugly:
You might think it’s a good idea to start with JWTs because you don’t have a lot of data - as time goes by the amount of data grows exponentially, and the situation easily spirals out of control, with an enormous amount of JWTs floating around in each request.

Bottom-line:
JWTs are ideal for simple identity-related data, and in general, it’s best to think of the claims and data in the JWT as hints about identity (given by the Identity-Management and Authentication layers) rather than verbatim data for authorization.

2. Overload input for OPA within the query:

Another option is to attach input for every policy query to OPA, adding the relevant data to it.
It will look something like this in python pseudocode wrapping OPA:

def delete_image(user_id, image_id):
    policy_json_data = {}
    policy_json_data[“user_roles”] = get_user_roles(user_id) # returns list of roles like [“editor”]
    policy_json_data[”user_images”] = get_user_images(user_id) # returns list of images [“img.png”]

# sends request that looks like this:
# localhost:8181 -i -d ‘{"roles": ["pro"], "related_images": ["image0.png", "image1.png"], image_id: “image2.png”}’ -H 'Content-Type: application/json'
# and returns true / false
    permitted = check_opa_policy(policy_json_data, “delete”, image_id) 
    if not permitted:
        raise(AuthorizationError)

The good:
Using this method is simple, and it ensures that only the relevant data is cherry-picked for each query sent, thus avoiding loading/storing a lot of data in OPA.

The bad:
This method prevents us from following one of the most important best practices in building authorization - decoupling policy and code. As our code now has to take on the responsibility of tailoring the data for OPA. Having policy and code mixed together in one layer creates a situation where we struggle to upgrade, add capabilities and monitor the code overall as it is replicated between different microservices. Each change would require us to refactor large areas of code that only drift further from one another as these microservices develop.

The ugly:
Having so much code repetition is an antithesis to the DRY principle - creating a multitude of complications and difficulties as our application evolves. Considering the example code above for instance, a very similar code will be written to delete_image, update_image, and get_image.

Bottom-line:
In general, it is best to leave this method for simple cases or to augment more advanced cases with cherry-picking.

3. Polling for data using Bundles

The bundle feature periodically checks and downloads policy bundles from a centralized server, which can include both data and policies. An example of a simple way to implement this solution would be running an Nginx container that serves the bundle files and configuring OPA to fetch data from it (using s3 buckets is also a common pattern). The configuration for OPA will be as follows:

services:
  nginx:
    url: https://my-nginx.example.com
    credentials:
      bearer:
        token: dGVzdGluZzp0ZXN0aW5n
        scheme: Basic

bundles:
  authz:
    service: nginx
    resource: /bundle.tar.gz

The good:
It allows you to load large amounts of data (much larger than the 2 previous methods), it has a delta bundle feature that lets you sync only new data (but not policy), it lets you have one source of truth, and it is more readable than JWTs.

The bad:
Using bundles doesn’t cut it when we have data that changes rapidly, as it requires triggering a full policy update for every small change - Making this a very inefficient process.

The ugly:
Even with the new delta bundle feature, you still need to manage and create the bundles on your own, and it works with polling which isn’t real-time.

In addition, being dependent on a polling interval means you have to choose between rapid polling which can result in high costs or slow polling which can lead to delays and risk of inconsistency.

The bottom line:
For cases where updates to data mainly come as part of the CI/CD cycle, bundles are a great option. Bundles can also work well for static or rather static applications. For modern dynamic applications, this option might be too slow/inefficient on its own.

4. Pushing data into OPA using the API

You can also push policy data into OPA with an API request - this approach is similar in most aspects to the bundle API, except it allows you to optimize for update latency and network traffic. It will look something like this in python pseudo-code:

def send_user_update_to_opa():
    requests.put(f”{opa_url}/users”, params={users: [user1,user2]})

def callback_on_new_user():
    all_users = get_all_users()
    send_update_to_opa(all_users)

In this example, we are updating the user list of OPA for each callback on new user creation.

The good:
This way you don’t need to load the entire bundle at every update, you can also update part of it, which is much more performant in terms of memory and network usage - as well as giving you more control of how you manage distributed data into OPA.

The bad:
Applying this method to import new kinds of data from different data sources is going to require a continuous effort of writing enormous amounts of code.

The ugly:
This method requires continuous maintenance - you can’t just set it up and forget about it. If left abandoned, this code will very quickly become obsolete.

The bottom line:
Great way to load data into OPA in a dynamic fashion, but requires a lot of development and administration in all but very simple cases.

5. Pulling data using OPA during Policy Evaluation

OPA includes a function (http.send()) that allows it to reach out to external HTTP servers during evaluation and request additional data. It will look something like this in Rego pseudo-code:


default allow = false
 
allow = true {
    input.method == "GET"
    input.path = ["getSalary", user]
    managers := http.send(get_managers_url)
    managers := managers[input.user][_]
    contains(managers, user)
}

You can see the call to http.send(get_managers_url) that returns the list of the managers to help evaluate the policy. Similarly, you can embed more functions into OPA as a plugin to fetch data as part of a query from other sources.

The good:
This is a solid option to use when you have a very large volume of data that is required to make permission decisions, and you cannot load it all into OPA.

The bad:
Using this method puts a strain on OPA as it always comes with network latency that slows all of your policy evaluations. Additionally, this method is prone to network errors.

The ugly:
Error handling with rego isn’t simple at all, and relying on this feature can lead to some frustrating results. While OPA and Rego can be used to evaluate policies very quickly, you may want to avoid adding more logic than you need.

The bottom line:
This is a great way to load data into OPA in a highly dynamic way without writing a lot of code. That being said, this solution is not applicable when the relevant data requires parsing or edge case handling, which Rego lacks.

6. OPAL (Open Policy Administration Layer):

OPAL is an open-source project for administering authorization and access control for OPA. OPAL responds to policy and data changes, pushes live updates to OPA agents, and thus brings open policy up to the speed needed by live applications.

To run OPAL with OPA you can simply use the Docker example. Send an update to OPAL on every change in your data or connect your data source's webhook with OPAL and let OPAL stream the updates to OPA.

The good:
OPAL includes live updates and Git tracking (GitOps) and saves you the hassle of having to write all the code by yourself like in the ‘Pushing Data with API’ option.

The bad:
OPAL is a fairly new library, it might take some time to learn and some work to integrate into your project.

The ugly:
First of all, OPAL is beautiful (But being one of the contributors to this open source project I might be biased). That being said, the architecture can be a bit more complicated than bundle server/JWTs, so you might need to take your time and make sure you understand it.

The bottom line:
OPAL is inspired by the way companies like Netflix work with OPA, but it requires some work to set up. Simple applications will do better with one of the other methods, but for full modern applications, OPAL is probably the more robust/reliable option.

Conclusion

There are various methods to build data fetching mechanisms - each of them having their own pros and cons.

Some of these methods (Including data in JWT tokens and using Overload input for OPA within the query) could only prove useful in simple cases, some (Polling for data using Bundles) lack effectiveness in dynamic applications. Pushing data with API is a good solution to load data into OPA in a dynamic fashion while requiring a lot of development and administration, and Pulling data using OPA during Policy Evaluation is not applicable when the relevant data requires parsing or edge case handling. OPAL has the advantage of being a more robust/reliable solution, but it requires you to adopt new open-source-based technology.
The most important thing to take from this review is understanding the complexities and challenges of building data fetching mechanisms correctly, and understanding that every method has its pros and cons.
⁠
⁠Still not sure which method is the right one for you and your architecture? Need someone to brainstorm with? Don’t be shy - reach out to us on our Slack community.

A Guide for an Awesome Custom Auth0 Universal login

OdedBD — Wed, 26 Jan 2022 10:13:52 +0000

Your login and sign-up screens are the gateway to your app - the first thing a person sees before entering your actual application. So, they better look amazing, if you want an awesome app.

While creating our own login screen at Permit.io, I had to review and collect data from multiple different guides, so I finally decided to incorporate them into one unified guide that will help you transform your own login screen completely.

In this guide, we will cover:

5 reasons why you should customize the default Auth0 login
How to edit the default Auth0 login template
How to edit the Auth0 default title and description
Which customization features are yet to be available

Using Auth0 authentication has its advantages - It’s fast, secure, and highly functional.
That being said, you can’t have the first thing your user sees when entering your app look like this:

5 reasons why you should customize the default Auth0 login -

While functional, using the default Auth0 login screen has some key issues:

While the login / sign-up screen is a crucial step in a user’s onboarding process, the default Auth0 login screen lacks some important elements - The company name is there, but the overall look is different. This makes the login screen seem like a foreign entity inside your application. And that’s not a good user experience.
The default option Auth0 provides in login through an external domain that belongs to Auth0, meaning each time someone wants to log in to use your application they are redirected to a domain outside that of your company. Your users might have no idea what Auth0 is, or why they are referred to this external website to provide their login information. This looks both unprofessional and unsecure.
This sense of unfamiliarity creates another issue: because the login screen doesn’t look like the rest of your company’s user interface, and it is based on a domain outside your company, it can be easily interpreted by the user as a phishing attack.
The message displayed reads: “Log in to ‘Company Name’ to continue to ‘Application Name’”. Not only is this not the most inviting message, changing it is no trivial task (As we will see later on).
The login interface uses only a small percentage of your screen, the rest of it being just one color, making it look quite dull and uninviting on one of the most important screens in your entire app.

While the good news is that most of these features are customizable, the bad news is that implementing these customizations is no easy feat, and far from intuitive. Hence this guide 😉

What can we do about this?

Overcoming these issues took me a while, but we were very pleased with the end result:

So how did we get here? Let’s review the steps:

1. Enabling custom domains

As we have stated before, having your login/signup based in a domain outside your company creates various issues. Apart from that, Auth0 only allows you to customize your login screen by using a custom domain - which is a paid feature.

To do this -

Choose the correct tenant (most likely production).
In the left sidebar go to Branding > Custom Domains.
(If you haven’t upgraded your plan to include custom domain support, you will need to do that first).

Approve your custom domain through the instructions provided by Auth0 to prove that you actually own it (This includes adding some TXT entries to the domain).
This is what an approved custom domain should look like (notice the ready status):

2. Editing the login template

Now that we have a custom domain, we can get to editing the login screen itself.

If you check out Auth0’s documentation you will notice they suggest using POST requests to update the template. This means posting all of the code for the entire page every time we want to make the smallest of changes. That can be a huge hassle.

To overcome this issue, I used Auth0 CLI (That’s still in beta, but works almost perfectly) which utilizes Storybook. Auth0 CLI allows you to edit the login template from your code editor while previewing those changes in Storybook as you go along.

How to do this:

Download Auth0 CLI:

On Mac:

brew tap auth0/auth0-cli && brew install auth0

On Linux:

brew tap auth0/auth0-cli && brew install auth0

On windows (With Scoop):

scoop bucket add auth0 https://github.com/auth0/scoop-auth0-cli.git 
⁠scoop install auth0

Check this link for more options.
⁠

auth0 login

Run the following command:

auth0 branding templates update

This will open your default code editor (I recommend setting VSCode as your default editor), and a Storybook window in your browser, previewing the current state of your login screen.

When you make changes in your code editor, you see them updated live in the Storybook preview window.

This is how the StoryBook preview looks like

Remember to add {%- auth0:head -%} in the HTML head tag ⁠and {%- auth0:widget -%} where you want the Auth0 widget to be injected.

This is an example of a basic template that displays the Auth0 login, (we also shared our full template at the end of this guide):

⁠html
<!DOCTYPE html><html>
  <head>
    {%- auth0:head -%}
  </head>
  <body>
    {%- auth0:widget -%}
  </body></html>

When you close the editor, Auth0 CLI will ask you if you want to update the login template.

Approve, and you’re done!

Important note:
The authentication widget previewed on Storybook is not identical to the actual one that is going to appear on your website. These could also display a bit differently on mobile/different screens - so make sure to recheck everything in your real environment after updating your template.

Note the Storybook preview (Left) vs. the actual version (right).

⁠

3. Editing Auth0 widget default title and description

⁠In this part, I’ll explain how to change the default text templates provided in the Auth0 login screen through API management. The default text will look like this:

To do this:

First, you will need to get your API management token: Go to Applications > APIs, click on Auth0 Management API. Go to the API Explorer tag, and copy the token by clicking the copy icon on the right.

Go to the Auth0 “prompt: login” Documentation, and get the names of the strings you want to change. For example, the key for the following login screen string:

Log in to ${companyName} to continue to ${clientName}

Is description.

Go to “Set custom text for a specific prompt” in Auth0’s API management docs.
On the top left side of the screen, click “Set API Token”, and paste the API token you copied.

Select the prompt you would like to make changes to (in our case: login)
Select the language (in our case: EN - English)
Under “body” - add all of the changes you wish to make in this prompt (in our case: description and title)

NOTE: If you want to change more than one prompt, you have to make both changes first, and then save them together. If you do them separately the first will revert to its original state.

Click TRY to save your changes.

You may want to repeat this process to edit your signup widget as well. To do this, locate the text you want to change here, and repeat the process while choosing signup instead of login
in all the steps.

4. Things you cannot do with Auth0 universal login

As of the writing of this guide, a feature to change the login widget to request the user to repeat the password on signup is not yet available. A GitHub issue for this has been open since 2014, yet no relevant action was taken.

*I hope this guide enabled you to set up your own authentication via Auth0. *

Usually, once you have authentication set up, the next step is to do authorization!
⁠Check out our blog post on the 5 best practices for building cloud-native permissions, or visit permit.io to learn more about getting permissions as a service.

You can check out our own template on Github

---canonical_url:https://www.permit.io/blog/custom-auth0-universal-login