Cedar best practices

The best practices included here outline the most up-to-date recommendations to get the most out of using Cedar as your authorization engine.

Best practices

Map actions to the business domain

When designing your authorization model, the actions you define should be business actions, not API actions. POST and GET should not be defined as actions, instead focus on actions your users perform. For example, a support technician may perform the CreateSupportCase, ListSupportCase, and ViewSupportCase actions.

Model all permissions in Cedar

Before you started using Cedar you may have used a permissions table in your database that linked principal IDs to resource IDs. When moving to Cedar it’s best practice to move all your permissions determination logic to Cedar policies. If you have a permissions table, each row of that table would become a separate Cedar policy.

Take advantage of user groups

When creating your authorization model there might have been multiple user types created, such as Admin, CustomerSupportTech, FinanceUser, etc. In Cedar, we recommend only creating one user type, such as User, and creating Groups that map to the different kinds of users you have and control their permissions at the group level.