Designing an authorization model for your application - Amazon Verified Permissions

Designing an authorization model for your application

As you prepare to use the Amazon Verified Permissions service within a software application, it can be challenging to leap immediately into writing policy statements as a first step. This would be similar to beginning development of other portions of an application by writing SQL statements or API specifications before fully deciding what the application should do. Instead, you should begin with a user experience, gathering a clear understanding of what end-users should see when managing permissions in the application UI. Then, work backwards from that experience to arrive at an implementation approach.

As you do this work, you’ll find yourself asking questions such as:

  • What are my resources? Do they have relationships to each other? For example, do files reside within a folder?

  • What actions can principals perform on each resource?

  • How do principals acquire those permissions?

  • Do you want your end-users to choose from predefined permissions such as “Admin”, “Operator”, or “ReadOnly”, or should they create ad-hoc policy statements? Or both?

  • Should permissions inherit across resources, such as files inheriting permissions from a parent folder?

  • What types of queries are necessary to render the user experience? For example, do you need to list all of the resources that a principal can access to render that user's home page?

  • Can users accidentally lock themselves out of their own resources? Does that need to be avoided?

The end result of this exercise is referred to as an authorization model; it defines the principals, resources, actions, and how they interrelate to each other. Producing this model doesn’t require unique knowledge of Cedar or the Verified Permissions service. Instead, it is first and foremost a user experience design exercise, much like any other, and can manifest in artifacts such as interface mockups, logical diagrams, and an overall description of how permissions influence what users see in the product. Cedar is designed to be flexible enough to meet customers at a model, rather than forcing the model to bend unnaturally to comply with a Cedar's implementation. As a result, gaining a crisp understanding of the desired user experience is the best way to arrive at an optimal model.

This section provides general guidance on how to approach the design exercise, things to watch out for, and a collection of best practices for using Verified Permissions successfully.

In addition to the guidelines presented here, remember to consider the best practices in the Cedar policy language reference guide.