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 for different policies for different deployments or configurations - such as Production, Dev, or Staging.
You can create and switch between projects through the project tab selected from the back-office's sidebar.
Notice when you switch environment the policy-editor will eb updated to reflect the new environment.
Project / Environnement Keys
Each project has a unique key that is used to identify it in the system, and access it via the SDK, API, and PDP. You link a service, application, or code to a project by using the project key in the SDK init call. Get your key from the "COPY SECRET KEY BUTTON" in the project tab available for each environnement.
Permit Object Model
Your workspace (aka organization) is at the root of the Permit object model (it's basically your tenant within Permit.) Within your workspace you can have multiple projects, and each project can have multiple environments each with their own set of policies and roles.
To simplify think of a project as different applications you'd want different policies for. To simplify think of an environment as different deployments you'd want different policies for.
Under each environment you'd 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 (e.g. in App-W in Production User-X has the Y-role in Tenant-Z ). You can have the same user belong to multiple tenants in the same environment, and to multiple environments/projects (Simply use the same identifier).