DEV Community: Amplication

Choosing Between Role-Based vs Claims-Based vs Permission-Based Access Control Mechanism

Amplication — Wed, 01 Mar 2023 05:19:14 +0000

With the world progressing towards cloud-native applications, the cyber threat landscape is also taking a revolutionary turn. As a result, it’s crucial to guard our applications and systems against internal and external security threats.

Most security risks to an organization are caused by insufficient and improper access control that may put the company at risk for fraud, unauthorized access to data and programs, or completely shut down or corrupt the computer servers and services. Therefore, it’s essential to secure organizational resources and information by restricting access and providing only the relevant permission to the appropriate entities to access and manipulate the data in the system.

This article will discuss the three primary access control mechanisms: role-based, claim-based, and permission-based access control, and provide guidance on which approach to select based on your requirements.

What is Access Control?

Access control governs who can access particular data, applications, and resources inside an organization and under what circumstances. Access control lets the right people in and leaves the wrong people out by granting the users an appropriate level of access using different mechanisms.

Organizations use authentication and authorization techniques to verify users. Depending on compliance requirements and security levels, access control models such as role-based, claim-based, and permission-based access controls prevent unauthorized access to sensitive data.

The following sections will review these different models, providing a comprehensive comparison.

Role-based Access Control (RBAC)

Role-based access control (RBAC) limits access (viewing, creating, editing, deleting) based on a user's role and responsibilities within an organization, preventing unauthorized access to critical resources. Therefore, an organization can use RBAC to allow some people, such as system administrators, to create or change files while allowing others to view them. As a result, access to sensitive information is restricted for lower-level users, tightening the organization's security measures for essential data.

Implementing RBAC

The main steps involved in implementing RBAC are as follows:

Define and determine the most sensitive resources and information that require controlled access.
Logically group the employees according to the workforce's functions and relationships to identify the organization's key roles.
Assign proper access rights to the roles based on their responsibilities.
Conduct periodic audits to check if a role has unnecessary access to a specific system and modify access levels accordingly over time.

Advantages of RBAC

Flexible: Any organizational structure changes can be applied quickly to users by modifying the corresponding roles.
Less administration work: Policies can be assigned to user groups instead of manually to individuals.
Secure: Utilization of the principle of least privilege reduces the risk of a data breach. Integrating third-party users is also more secure with RBAC, as we can give them strictly defined roles and permissions.

Disadvantages of RBAC

Assigning the appropriate roles can be challenging: Assigning people to ill-fitting roles or creating new roles against policies may lead to security gaps.
Role explosion: Roles minimize the potential for altering the permissions for a single entity, forcing administrators to create new roles to give an entity a customized set of permissions.
Less scalable and less dynamic: As the organization grows, RBAC may be difficult to maintain and manage due to the expansion of user categories and lack of compatibility of existing roles with the new organizational structure.
Coarse-grained and static: RBAC has fixed access rules that ignore other significant factors, such as time, location, or device, and limits access based only on a user's role.

Claims-based Access Control (CBAC)

Organizations may utilize claims-based access control (CBAC), also known as attribute-based access control (ABAC), either as a replacement or a supplement to RBAC to provide more granular access control.

CBAC restricts and provides access to critical resources based on a combination of three factors:

The user’s identity
The user's responsibilities
The context of the action performed.

Attributes or claims are used to identify an entity based on its characteristics and allow you to implement rich, complex access policies more simply. For example, if a user is promoted from marketing to management, their access permission would be modified due to the change in their business attributes rather than because a system administrator explicitly changed the specific user’s role.

Implementing CBAC

The basics steps involved in the CBAC process are:

Identify the attributes needed to specify access rules: Three main categories of claims are based on the entity.

Subject/user claims: Characteristics of a user trying to access a resource such as a username, job title, user ID, and security clearance.
Object/resource claims: Attributes of the resources such as filename, creation date, and ownership.
Context/environment claims: Environmental characteristics such as time, place, type of communication, and type of device used to access a resource.

Create a set of rules to determine the attributes that allow user access based on the requirements.
The given access to a user if the attributes match the rules specified.

Advantages of CBAC

Flexible, granular policies: Policies can be precisely defined, targetting specific attributes rather than the roles of the users.
Dynamic access: Since rules can be specified based on environmental parameters, access control can be done at runtime by evaluating the context and risk.
Scalable: Access can be easily given to new users without creating new policies or roles by simply assigning the attributes needed to access the resource.
Secure: With context-sensitive rules, user privacy and resources can be protected based on the situation where access is requested.

Disadvantages of CBAC

Implementation is time-consuming: Correctly identifying the mapping of authorization policies to attributes may consume time and resources.
Comparatively complex: Granularity introduces complexity.

Permission-based Access Control

Conceptually, permitting users means granting access to a resource or allowing them to execute a specific operation in a system. Therefore, permission-based access control (PBAC) is a technique that defines the set of actions each user in the organization is allowed to perform on each resource.

The image below illustrates how access is given to three entities using PBAC.

Source

Implementing PBAC

Enforcing PBAC is relatively straightforward compared to RBAC and CBAC. Access rules should be specified for each user as a tuple, indicating the resources and the permitted operations such as view, create, edit, and delete. Therefore, obtaining access rights to a resource means that, at the very least, the entity can read its content.

Advantages of PBAC

Fine granularity: Permission can be defined flexibly for each entity for each resource in the system.
Secure: Since customized access levels are defined for each entity, only the least privileges will be given for all users to perform their tasks.

Disadvantages of PBAC

Less scalable: When the number of users is high, managing permissions for each user individually is impractical.
Access is static: The permissions are not specified based on the environmental context of the users accessing the resources.

When to Choose Which?

Now that there is a clear understanding of each access control mechanism, let's compare the characteristics to identify the best use cases for each method. The table below shows a comparison of the three methods discussed.

Considering all these differences, here's a summarized set of guidelines for choosing a well-suited access control mechanism for your organization.

Wrapping Up

Access control is an essential step that needs to be taken to help ensure the security of your organizational resources.

RBAC, CBAC, and PBAC are three popular access control mechanisms with pros and cons. This article provides guidance on selecting an access control method based on your organizational structure and resources.

However, remember that these tips are highly generalized, and you might sometimes reap tremendous benefits from combining them rather than implementing a single access control mechanism.

How Amplication Can Help

Amplication provides a role-based permission model that is generated automatically with your code, saving you time setting up authentication and authorization in your app. You can create as many roles as needed and granularly set permissions per data model or specific fields for different roles. All the permissions are automatically enforced in the REST and GraphQL APIs including response filtering on specific fields.

Amplication uses the @nestjs/passport module as middleware to support authentication, providing a rich ecosystem of strategies that implement various authentication mechanisms.

Thank you for reading.

4 Common Mistakes Made by Node.js Developers

Amplication — Fri, 23 Dec 2022 06:39:39 +0000

The growth of Node.js is tremendous. It’s clear why — Node.js helps us move fast, it has a rich packages ecosystem, it’s battle-tested and the usage of JavaScript allows businesses to go truly full-stack and cut the development lifecycle short.

However, with great powers comes great responsibility (as I previously mentioned in my JWT article). After reflecting on the past 8 years of using Node.js, I decided to publish an article covering four common mistakes made by Node.js developers.

Most of these are not Node-specific but rather back-end general. However, I will refer to concrete Node.js examples that are relevant to any developer in the ecosystem.

Mistake #1 — Going live without well-defined log levels

I assume most of us are familiar with the concept of log levels (DEBUG, INFO, WARN, ERROR, etcetera).

I have seen many cases where a product team is rushed to deliver a new microservice and forgets about clearly defining these log levels.

There are two main drawbacks to this:

It will make it a lot harder for you and your teammates to identify and tackle issues in production if the logs are flooded with irrelevant messages, such as low-level DEBUG logs. These are not usually helpful for production workloads.
It will dramatically increase the bill of whatever log ingestion service you use. I have seen this first-hand — going live with a new service and BOOM — a massive bump in expenses. Log ingestion services charge you by throughput and/or storage. 💸

To tackle both points, make sure you use a logger with clearly-defined log levels. There are plenty of great logger libraries for Node.js (winston, pino, morgan) which provide you with a simple API for emitting logs of different types.

Additionally, ensure you are able to configure the log level of your application at runtime via an environment variable (commonly seen is LOG_LEVEL). This way you can adjust the log level according to your needs, whether you are working locally (set in your .env file) or when running workloads on cloud environments (Staging, Production etcetera).

Mistake #2 —Recklessly choosing your Dockerfile’s base image

It is extremely common to deploy Node.js apps as containers and there are many benefits to doing so. When defining your Dockerfile, you declare the base image to use at the top of the file. For example:

FROM node:18

This indicates that your image will be built based on the official Node.js version 18 image. What developers often don’t pay attention to, is the potential negative impact of this.

Let’s stick to the Node 18 example. The above image is based on the Debian operating system. This is a full operating system which adds a lot of overhead for a typical back-end API written in Node.js. The image size will be very large, take a long time to build, cost more to store, and more resources will be used by the container, thus affecting your scalability and performance.

Solving this is quite easy — use an alternative image. It’s very common to see alpine and slim flavours of images. In a nutshell, these are Linux-based operating systems that are very lightweight and don’t contain many of the binaries and libraries preinstalled in a fully-featured operating system.

When browsing the Node.js image tags on Docker Hub, we can see that both alpine and slim flavours are available. By simply making this change:

FROM node:18-alpine

We saved a significant amount of time building the image and minimised the operating system’s overhead, thus optimising the overall performance of our containers. Additionally, the resulting image size is significantly smaller which makes it faster to build and push, and cheaper to store on a remote container registry. Win! 🥳

A whopping x5 reduced image size. Now imagine the impact of this in a team that runs multiple CI pipelines for multiple services every day! 🤯

Note that while this works in most cases, sometimes your app’s packages require certain low-level libraries that aren’t included in lightweight images by default. You will need to install them as a RUN statement in your Dockerfile. Still, the benefits are well worth it!

Mistake #3 — Not using asymmetric encryption when signing JSON Web Tokens (JWT)

As I wrote in my article, "JSON Web Tokens (JWT) — the only explanation you will ever need", JSON Web Tokens are truly changing the world.

It’s a fantastic tool to have when developing microservices for achieving distributed authorization.

The mechanism is quite simple — you sign and verify tokens using cryptography.

The simplest form of implementation allows you to use a secret (for example, verySecret123 to sign tokens. You will then use the same secret to verify those tokens. This is a symmetric signature, because the same value is used to sign the token as well as verify it.

If doing this in a distributed architecture, every one of your services will need access to that secret in order to verify tokens. This increases the chance of your secret being stolen, which may result in an attacker signing fake tokens, allowing them to elevate access or impersonate and perform operations on behalf of others. This is often overlooked, and poses a serious security risk! 🚨

The better way to sign JWTs is using an asymmetric algorithm. Instead of using a raw secret value to sign and verify the tokens, you use a keypair (for example, generated via openssl). The result is a private key used to sign tokens, and a public key used to verify tokens.

This method is significantly more secure, as it allows the signing authority (for example your Auth Service) to exclusively possess the private key and use it to sign tokens.

Any other service in your architecture that needs to accept API requests can possess the public key and use it to verify tokens.

This greatly reduces the risk of your private key being stolen and exploited to generate tokens of false identities and/or elevated privileges, by limiting the number of service with access to it.

If you are curious and want to know more, I cover this in detail in my bespoke JSON Web Tokens article.

Mistake #4 — Storing passwords without unique salting

In general, I am strongly against storing passwords on your systems, unless this is your core business (which entails heavy regulations and auditing). It’s all fun and games until it goes wrong. 👎

Regardless, many companies opt-in to store passwords on their own systems. This is also an important topic for back-end developers to be familiar with.

➡️ Before talking about this mistake, a quick primer on password authentication…

Remember that password validation is not an "encryption-decryption" operation. You take a raw password, run it through a hashing algorithm and store it, so that myPassword123 becomes something like 487753b945871b5b05f854060de151d8 which gets stored in a database. Then, upon signing in, you take the user’s input and hash it. You then compare the result hash to that stored in your database, and if it’s a match — you authenticate the user.

➡️ Now we are aligned! There are four levels of security when it comes to storing passwords:

Storing raw passwords 😭. This is an absolute no-no. In the case of a database breach, and attacker will get access to the raw passwords of all of your users.
Hashing passwords (no salt) 😖. You take a user’s password and run it through a hashing algorithm as described above, and store it in your database. This will prevent an attacker from getting access to raw passwords which is great. However, since you simply hashed the password, an attacker can utilize a Rainbow Table attack in which they compare hashed passwords against their respective raw passwords, and identify matches. Remember that running myPassword123 through a simple hashing algorithm will always produce the same result!
Hashing passwords + global salt 🥴. This method is very similar to the above, except you add a little "salt" to the password before hashing it. So you don’t really hash myPassword123, but instead you hash myPassword123+SOME_SALT. This means that a common password such as myPassword123 will look different as a hash in your database, and will protect you from rainbow table attacks. However, if your global salt is exposed, it becomes easier for an attacker to identify common passwords stored in your database.
Hashing passwords + unique salt per password 💪. This is the most robust and standard method of storing passwords today. Every password stored in your database is hashed with a unique salt. This significantly mitigates the chance of an attacker putting their hands on the raw passwords of your users, even in the case of a database breach. Implementing this is very easy, utilising a package such as Bcrypt.

Again, store your users’ passwords responsibly! Use a reliable and certified service to do that if you can, then you can focus on building your core product.

Folks — this is a reminder that you should always use a password manager to auto-generate passwords wherever you sign up. Never re-use the same password. You don’t know how your passwords are handled! ⚠️

Closing Remarks

If you're looking to build a new backend service and want to avoid some of these common mistakes, Amplication can help. Amplication makes it easy to use JWT, handles authentication securely, and is designed to support enterprise needs.

That’s all! I hope you enjoyed this article. Let me know what you think in the comments. If there are any other topics you find interesting, I’d love to know and perhaps even write about it!

How to Start Your Next Backend Project - Boilerplates, Starters & Frameworks

Amplication — Tue, 20 Sep 2022 07:06:18 +0000

A new backend project is on the horizon, and with every new project come new challenges and opportunities. You can implement everything in a way that fits your needs and the project’s goals, but every decision comes with its pros and cons.

Modern software development moves fast, and since your last project, the technology landscape has changed, while libraries, services, and frameworks might have improved drastically.

Questions you may face include: should you build something new from scratch, leverage code from previous projects, or choose something completely different as a base?

Different approaches will deliver various benefits—you might want to save yourself time, or you might choose to go for more flexibility. This article will help you to find the right direction for your given project.

Building your backend from scratch

The most low-level approach is building everything from scratch. But even this has a wide range of possibilities, with some tech companies producing everything from the ground up—hardware, firmware, operating system, web servers, etc.

Pros:

You get to choose everything, meaning maximum flexibility. If you need every ounce of performance you can get, build your system with C or Rust. If you have special security requirements, choose a hardened Linux distribution or Docker image.

Cons:

When you’re building an application from scratch, you will spend most of your time on undifferentiated heavy lifting. This covers everything from authentication, authorization, and identity management to over-sorting, filtering, data validation, and more.

You will also spend a significant amount of time on non-functional requirements. To run systems in the cloud in a controlled way, you need to implement observability and error reporting.

Building this all by yourself can lead to you losing focus on actual business problems very quickly, and even if not, it will still slow you down.

Using templates from past projects

If you’re building the same types of backends again and again, you’re in a lucky spot. This recurrence lets you use boilerplate code from your past projects.

Pros:

No need to start from zero; just copy the code and replace the functional parts of the system.

This also lets you copy the experience encoded in the modules and libraries you’ve built over the years. You don’t need to explicitly think about what exactly you did back when; it’s all there, right in the source code.

Cons:

The problem with this approach is that you now have two codebases that are very similar but distinct. And since you copied the code, you copied the bugs as well, so you need to apply the same fixes to both of them.

Furthermore, you’re copying the old versions of libraries used to build a previous system. While they might be good enough in most cases, this can lead to bugs and difficult maintenance.

Using boilerplates

This approach is like the previous one, but you copy somebody else’s old project instead of your old project. There are many such boilerplates on GitHub that are maintained by communities. Some are very basic, like a Node.js REST API boilerplate, while others are higher level and include frameworks like Express and Socket.IO.

Pros:

The advantage here, versus copying your own backend project, is usually that those boilerplates are made to be copied and thus easier to fit to your task. And since communities maintain them, you get the aggregated experience of many people, not just you or your team. The many eyes looking over these projects lead to bug fixes and library updates, meaning you can get better quality without doing any extra work.

Cons:

The downside of this approach is that it is more generic than your own past projects. The code will not be tailored to your needs but made for a vast number of developers. This might require you to do more integration work and adjustments. Also, you know your code, while a new boilerplate can come with a considerable amount of code, which you’ll need to learn.

Then, there’s the downside of your own codebase copy—after you copy the boilerplate, you’ll have to maintain all the parts that changed from the original.

Using frameworks

Frameworks form the foundation of many modern projects. You can use them when building from scratch or get them alongside a boilerplate that sets up the basic project structure.

Pros:

Like boilerplates, frameworks come with the experience of other developers baked in. But unlike boilerplates, they do this with a package that other people will maintain. You simply update the dependency in your project when bugs are fixed and don’t need to keep track of changes to your code.

Cons:

Frameworks prescribe some structure for your project because they are often opinionated. Your project structure will look different if you build your system with NestJS instead of Sails.js.

Frameworks often have their own terminology and way of doing things as well, which might not be easy for newcomers to grasp. Sure, you know what an API endpoint and a URL are, but do you know what a resolver or a mutation is? You’ll need to learn these things to be productive with a new framework.

Another factor to consider is that if you don’t copy a boilerplate for the framework you’re using, you’ll still need to write some non-functional boilerplate code yourself.

Using Amplication

Amplication is the fast alternative to the approaches mentioned above. It lets you, the developer, configure the data models and relations with a UI or CLI, and it generates a functional backend code with Node.js, NestJS, Prisma, Postgres, Docker files, and more.

Pros:

Amplication lets you configure role-based access control, application data models, and other configurations using a graphical data-model editor or a CLI.

The generated code is pushed continuously to a Git repository. Hence, as with any code, you have complete control over the generated code, and you can customize and extend the code as you wish.

Unlike any other boilerplate solution, the code generated by Amplication includes all the specific models and DTOs your application needs, including data validation, types, and the relation between models.

The code is generated with authentication, authorization, filtering, sorting, pagination, logging, and docker files—it even has formatting and linting rules.

You can select between a GraphQL API, REST API, or both. Plus, you can get a fully functional admin UI for CRUD operations on all your data models, including relations.

Amplication is built around well-known frameworks and libraries, so it comes with the experience of many developers, not just the Amplication team.

With Amplication, you are the owner of the generated code, and you can use it and deploy it any way you like.

Cons:

The code generated by Amplication is highly opinionated, with a specific technology stack, which may not be a good fit for all use cases.

Summary

[There are many different approaches to building your new backend project.]( Depending on your requirements, you can go as deep as you like and build everything from scratch to get maximum flexibility. On the other hand, the open-source ecosystem is extensive, so there might be some boilerplate or framework out there for you to save both time and money.

If you want to move fast and still be flexible in the future, Amplication is a solid alternative. It allows you to build your application by writing minimal code for the infrastructure while focusing your efforts on writing business logic from day one.

Read one of our tutorial articles to get started.

Release 0.15.0 - Support for Microservices Architecture

Amplication — Sat, 20 Aug 2022 07:09:02 +0000

Amplication Release 0.15.0 offers support for microservices through the introduction of a Project hierarchy.

The Project groups together multiple resources used and created by Amplication, enabling support for multiple use cases. This simplifies the creation of connected Services, and makes it much easier to sync with GitHub across multiple Services.

These developments will be especially welcome if you work at the enterprise-level, but it will enable all developers, individually or in teams, to move into the big-time of microservices architecture.

Amplication is still the same node js app development platform taking the donkeywork out of backend development, but the new workflow means we need to see things differently. In the past we talked about Amplication only as a tool to create the backend for your apps. We still do that, of course, but today we empower you to see and develop on a broader canvas by working with Project hierarchies.

What are Projects, Resources, and Services?

Starting with Release 0.15.0, Projects , Resources , and Services are key concepts that drive Amplication’s workflow.

Project

A Project is a hierarchy within Amplication that groups together multiple resources.

The project hierarchy supports use cases that are relevant to building a microservices architecture, with or without a monorepo.

As a first step, Amplication 0.15.0 includes the following resources:

Project configuration (default)
Services

Resource

A resource is any of the elements that go into creating a project with Amplication, such as Project Configuration and Service.

In future releases we will introduce many more types of resources. This is where the Project concept will really come into its own - by supporting the generation of a full microservices architecture including message brokers, storage, API gateways, and more.

Service

A service is the output generated by Amplication.

We used to call this output an app, but this implies that it is an application installed by the user. Services do not necessarily require user involvement, and so better describes the situation when each Service is one element in a solution.

How does Amplication's project hierarchy make your life easier?

In addition to the the ease of creating multiple connected services, Projects make your life easier by providing the following functionality:

Connecting to a single Git repo at the Project level. This will save you a lot of time when configuring a big project with many services, as you won’t need to connect each service manually. But rest assured - you remain in control, with the ability to override the settings at the Service level if you want to connect a specific Service or all Services to different repositories.
A single commit at the Project level. This will manage changes across different services in the project, generate the code for all services, and get a PR for each.

How has the Amplication interface changed?

As you would expect, we have revamped the Amplication interface to support the new Project hierarchy and Service creation workflows. Here is a brief look at some of the changes.

Go to a Workspace and select a Project from the list (or add a new Project).

Click the Project Configuration banner and use the Project Configuration dashboard to configure your project.

Then, from the workspace, select New Service and configure the settings on the new Amplication Service Creation Wizard. This new feature simplifies the process of building a Service.

Click Create Service and use the Service dashboard to configure your Service.

The service you have just created is added to your Project.

To view code or commit on the project level, select from the Resource List at the top of the screen.

What happens to existing apps?

If you have apps that were created in a previous Amplication release, each app will be wrapped into a new project, with the app presented as a Service in the Project.

Updates to Prisma, Lerna, and other packages

As we worked on Release 0.15.0, we performed the usual chore tasks to make sure the internals of our codebase are up to date and functioning properly.

Most noticeably:

A new @amplication/nest-logger-module package used for logging.
Updated Prisma to version 5.4.3.
Enabled Nx in Lerna. In the future, we plan to perform a full Nx migration.

If you want to dig deeper, check out the GitHub Release Changelog.