Cerbos Playground - Prototype, test and share policies
Product Packaging
A SaaS business typically bundles up products/features into packages and sells them to customers.
Customers will sign a contract for a package for a number of years.
As the product evolves new features come along and a business wants to be able to release these to different customers based on which package they have. This maybe for free, or they will want to upsell them onto a new package which includes it.
Due to this, every customer could have a slightly different set of products available to them. By using Cerbos policies, the products that a customer has access to can be done via configuration rather than coding it into the application logic.
A principal (user) is usually attached to an organisation (eg the customer) which has a package attached to them. This can be used to then work out which products the user has access to.
Packages + Products
In this example there are 4 active packages:
- 2018 Experiences (a legacy package)
- 2021 Start
- 2021 Grow
- 2021 Pro
These packages control access to these products:
- Social Proof
- Custom Experiences
- Integrations
As seen in the principals, the package is defined as an attribute called package.
The mapping between the two is done inside the packageRoles.yaml which grants the user a role for the product eg the 2021 Grow package gives the user the product_socialProof and product_customExperiences roles.
In the application logic a single call can be made to the products resource with the list of products that the application has and Cerbos returns the list of products access is allowed to, and those not (so that a nice message to the user can be shown to up-sell them).
Supporting Trials
Additionally, it is common to allow a customer to trial a specific product for a limited time as a way to upsell them onto a higher package. This can be done but putting the product name into the trial list in the user’s attributes.
Extending
Further per-product permissions can be added by building onto top of the derived product roles eg an customExperiences:publish action could be defined which uses the product_customExperiences parent role.
Principal
Who is performing the action(s)?
User with 2021 Start Package
{
"id":"123",
"roles":[
"USER"
],
"attr":{
"package":"2021_START"
}
}
Resource
What is being accessed?
{
"id":"123",
"kind":"products",
"policyVersion":"default",
"attr":{}
}
Actions
List of actions the principal is attempting to do with the resource
products Actions |
Result |
|---|---|
| Denied | |
| Denied | |
| Allowed |
Aux Data
Additional request context
Request
The HTTP request payload to Cerbos PDP
Response
The HTTP response from Cerbos PDP
Welcome to the Cerbos Playground
This environment allows your to build, test and debug authorization policies in realtime and share examples with your team.
Full documentation can be found at docs.cerbos.dev