Projects & Environments

In this section we will dife into details how Projects and Environments work within Permit.io.

Projects

Projects are the highest level of encapsulation for your authorization. Every unique service or application that requires its own set of policies and roles is a project. In addition, each project can support multiple environments - allowing different policies for different deployments or configurations.

Within your organization, you can have multiple projects. Each project represents your offerings, where an offering can be a different product, software or tool. By default, we defined the "Default Project" for you.

You can manage projects from the Projects page.

note

If you have one product line, you can ignore this hierarchy level.

If your organization needs to deal with multiple projects, you can add this project directly within the Projects page. We also provide the functionality for filtering through projects, to provide you with a more conrete view, and of course, you also get the ability to edit and delete projects as you wish.

Environments

Within your project, you create environments that suit your needs e.g. dev, staging, production etc.

info

Notice when you switch environment the Policy Editor will be updated to reflect the new environment.

Every environment has a secret key that you use to check for permissions with the Permit's SDK and API. We offer simple functionality so that you can easily copy your keys, rotate them if you want to maintain your secuity to your desired standard, edit the environment to you liking, delete it if need be, and most importantly change environment which is as simple as a click of a button.

You can manage environments from the Project page.

Permit Object Model

Your workspace, or in other words, your organization, is at the root of the Permit object model. Within your workspace you can have multiple projects, and each project can have multiple environments, each with their own set of policies and roles.

tip

Think of a project as different applications you would want different policies for.

Think of an environment as different deployments you would want different policies for.

Under each environment you will find:

• your tenants (think: your customers)
• your users
• your policy and roles
• your resources and actions (think: the layout of your application and its enforcement points)

Within each environment - Users are linked to tenants via roles

generic example

In app-W that's deployed to production, user-X has the role-Y in tenant-Z.

real-life example

Let's assume we have e-learning platform deployed into production.

One of the customers named John Smith, has been enrolled as a student in the payed "Introduction to Web Development" course.

You can have the same user belong to multiple tenants in the same environment, and to multiple environments/projects.