├── .github └── ISSUE_TEMPLATE │ └── documentation-bug-report.md ├── .gitignore ├── Best Practice Topics on hold ├── bp-all-about-the-data.md ├── bp-fine-grained-perms.md ├── bp-group-vs-attribute.md ├── bp-minimize-number-of-entities.md ├── bp-permissions-in-attributes.md ├── bp-resource-lives-in-container.md ├── bp-separate-principals-from-resource-containers.md └── bp-transitive-attributes.md ├── LICENSE ├── NOTICE ├── README.md └── docs ├── .markdownlint.yaml ├── 404.html ├── CNAME ├── Gemfile ├── Gemfile.lock ├── Gemfile.orig ├── _config.yml ├── _config.yml.orig ├── _includes ├── head_custom.html ├── nav_footer_custom.html └── toc_heading_custom.html ├── _layouts └── forward.html ├── _sass ├── color_schemes │ └── awsstyle.scss ├── fonts.scss └── fonts │ └── AmazonEmber_W_Rg.woff2 ├── authorization.md ├── bp-implementing-roles-attributes.md ├── bp-implementing-roles-groups.md ├── bp-implementing-roles-templates.md ├── bp-implementing-roles.md ├── bp-meta-permissions.md ├── bp-mutable-identifiers.md ├── bp-naming-conventions.md ├── bp-normalize-data-input.md ├── bp-populate-policy-scope.md ├── bp-using-the-context.md ├── collections ├── _auth │ ├── authorization.md │ ├── entities-syntax.md │ └── images │ │ ├── AVP-BASICS.jpg │ │ ├── Cedar 1 - black.png │ │ ├── Cedar 1 - white.png │ │ ├── Cedar 2 - black.png │ │ ├── Cedar 2 - green.png │ │ ├── Cedar 2 - white.png │ │ ├── Cedar1-green.png │ │ ├── PhotoFlash.drawio │ │ ├── PhotoFlash.png │ │ ├── entities.png │ │ ├── hierarchy.png │ │ ├── quotas-transitive-parents.png │ │ ├── resource-lives-in-container.png │ │ ├── security-of-cedar.png │ │ ├── separate-principals-from-resources-2.png │ │ ├── separate-principals-from-resources-3.png │ │ ├── separate-principals-from-resources.png │ │ ├── source │ │ └── entities.drawio │ │ ├── structure-of-policy.png │ │ ├── transitive-attributes-2.png │ │ ├── transitive-attributes-3.png │ │ └── transitive-attributes.png ├── _bestpractices │ ├── bp-compound-auth.md │ ├── bp-fine-grained-permissions.md │ ├── bp-implementing-roles-attributes.md │ ├── bp-implementing-roles-groups.md │ ├── bp-implementing-roles-templates.md │ ├── bp-implementing-roles.md │ ├── bp-meta-permissions.md │ ├── bp-mutable-identifiers.md │ ├── bp-naming-conventions.md │ ├── bp-normalize-data-input.md │ ├── bp-other-considerations.md │ ├── bp-overview.md │ ├── bp-populate-policy-scope.md │ ├── bp-relationship-representation.md │ ├── bp-resources-containers.md │ ├── bp-separate-principals.md │ ├── bp-using-the-context.md │ └── images │ │ ├── AVP-BASICS.jpg │ │ ├── Cedar 1 - black.png │ │ ├── Cedar 1 - white.png │ │ ├── Cedar 2 - black.png │ │ ├── Cedar 2 - green.png │ │ ├── Cedar 2 - white.png │ │ ├── Cedar1-green.png │ │ ├── InvertedGroupHierarchy.jpg │ │ ├── PhotoFlash.drawio │ │ ├── PhotoFlash.png │ │ ├── ResourceHierarchy.jpg │ │ ├── entities.png │ │ ├── hierarchy.png │ │ ├── quotas-transitive-parents.png │ │ ├── resource-lives-in-container.png │ │ ├── security-of-cedar.png │ │ ├── separate-principals-from-resources-2.png │ │ ├── separate-principals-from-resources-3.png │ │ ├── separate-principals-from-resources.png │ │ ├── source │ │ └── entities.drawio │ │ ├── structure-of-policy.png │ │ ├── transitive-attributes-2.png │ │ ├── transitive-attributes-3.png │ │ └── transitive-attributes.png ├── _other │ ├── doc-history.md │ ├── images │ │ ├── AVP-BASICS.jpg │ │ ├── Cedar 1 - black.png │ │ ├── Cedar 1 - white.png │ │ ├── Cedar 2 - black.png │ │ ├── Cedar 2 - green.png │ │ ├── Cedar 2 - white.png │ │ ├── Cedar1-green.png │ │ ├── PhotoFlash.drawio │ │ ├── PhotoFlash.png │ │ ├── entities.png │ │ ├── hierarchy.png │ │ ├── quotas-transitive-parents.png │ │ ├── resource-lives-in-container.png │ │ ├── security-of-cedar.png │ │ ├── separate-principals-from-resources-2.png │ │ ├── separate-principals-from-resources-3.png │ │ ├── separate-principals-from-resources.png │ │ ├── source │ │ │ └── entities.drawio │ │ ├── structure-of-policy.png │ │ ├── transitive-attributes-2.png │ │ ├── transitive-attributes-3.png │ │ └── transitive-attributes.png │ └── security.md ├── _overview │ ├── dropped-topics.zip │ ├── images │ │ ├── AVP-BASICS.jpg │ │ ├── Cedar 1 - black.png │ │ ├── Cedar 1 - white.png │ │ ├── Cedar 2 - black.png │ │ ├── Cedar 2 - green.png │ │ ├── Cedar 2 - white.png │ │ ├── Cedar1-green.png │ │ ├── InvertedGroupHierarchy.jpg │ │ ├── PhotoFlash.drawio │ │ ├── PhotoFlash.png │ │ ├── ResourceHierarchy.jpg │ │ ├── entities.png │ │ ├── hierarchy.png │ │ ├── quotas-transitive-parents.png │ │ ├── resource-lives-in-container.png │ │ ├── security-of-cedar.png │ │ ├── separate-principals-from-resources-2.png │ │ ├── separate-principals-from-resources-3.png │ │ ├── separate-principals-from-resources.png │ │ ├── source │ │ │ └── entities.drawio │ │ ├── structure-of-policy.png │ │ ├── transitive-attributes-2.png │ │ ├── transitive-attributes-3.png │ │ └── transitive-attributes.png │ ├── patterns.md │ ├── resources.md │ ├── scenario.md │ └── terminology.md ├── _policies │ ├── images │ │ ├── AVP-BASICS.jpg │ │ ├── Cedar 1 - black.png │ │ ├── Cedar 1 - white.png │ │ ├── Cedar 2 - black.png │ │ ├── Cedar 2 - green.png │ │ ├── Cedar 2 - white.png │ │ ├── Cedar1-green.png │ │ ├── PhotoFlash.drawio │ │ ├── PhotoFlash.png │ │ ├── entities.png │ │ ├── hierarchy.png │ │ ├── quotas-transitive-parents.png │ │ ├── resource-lives-in-container.png │ │ ├── security-of-cedar.png │ │ ├── separate-principals-from-resources-2.png │ │ ├── separate-principals-from-resources-3.png │ │ ├── separate-principals-from-resources.png │ │ ├── source │ │ │ └── entities.drawio │ │ ├── structure-of-policy.png │ │ ├── transitive-attributes-2.png │ │ ├── transitive-attributes-3.png │ │ └── transitive-attributes.png │ ├── json-format.md │ ├── level-validation.md │ ├── policy-examples.md │ ├── syntax-datatypes.md │ ├── syntax-entity.md │ ├── syntax-grammar.md │ ├── syntax-operators.md │ ├── syntax-policy.md │ ├── templates.md │ └── validation.md └── _schema │ ├── human-readable-schema-grammar.md │ ├── human-readable-schema.md │ ├── images │ ├── AVP-BASICS.jpg │ ├── Cedar 1 - black.png │ ├── Cedar 1 - white.png │ ├── Cedar 2 - black.png │ ├── Cedar 2 - green.png │ ├── Cedar 2 - white.png │ ├── Cedar1-green.png │ ├── PhotoFlash.drawio │ ├── PhotoFlash.png │ ├── entities.png │ ├── hierarchy.png │ ├── quotas-transitive-parents.png │ ├── resource-lives-in-container.png │ ├── security-of-cedar.png │ ├── separate-principals-from-resources-2.png │ ├── separate-principals-from-resources-3.png │ ├── separate-principals-from-resources.png │ ├── source │ │ └── entities.drawio │ ├── structure-of-policy.png │ ├── transitive-attributes-2.png │ ├── transitive-attributes-3.png │ └── transitive-attributes.png │ ├── json-schema-grammar.md │ ├── json-schema.md │ └── schema.md ├── doc-history.md ├── entities-syntax.md ├── fonts ├── amazonember_w_rg.woff2 ├── vaultalarm-regular.otf └── vaultalarm-sharp.otf ├── images ├── AVP-BASICS.jpg ├── Cedar 1 - black.png ├── Cedar 1 - white.png ├── Cedar 2 - black.png ├── Cedar 2 - green.png ├── Cedar 2 - white.png ├── Cedar1-green.png ├── PhotoFlash.drawio ├── PhotoFlash.png ├── entities.png ├── favicon.ico ├── hierarchy.png ├── quotas-transitive-parents.png ├── resource-lives-in-container.png ├── security-of-cedar.png ├── separate-principals-from-resources-2.png ├── separate-principals-from-resources-3.png ├── separate-principals-from-resources.png ├── source │ └── entities.drawio ├── structure-of-policy.png ├── transitive-attributes-2.png ├── transitive-attributes-3.png └── transitive-attributes.png ├── index.md ├── js ├── awsdocs.css ├── github.min.css ├── highlight.min.js └── hljs-cedar.min.js ├── json-format.md ├── overview └── best-practices.md ├── scenario.md ├── schema-grammar.md ├── schema.md ├── security.md ├── syntax-datatypes.md ├── syntax-entity.md ├── syntax-grammar.md ├── syntax-operators.md ├── syntax-policy.md ├── templates.md ├── terminology.md └── validation.md /.github/ISSUE_TEMPLATE/documentation-bug-report.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Documentation bug report 3 | about: Create a report to help us improve 4 | title: "[Cedar Doc Issue]" 5 | labels: '' 6 | assignees: bisdavid 7 | 8 | --- 9 | 10 | **What were you trying to do?** 11 | 12 | **What is wrong and why?** 13 | 14 | **What do we need to do to fix this?** 15 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | docs/_site/ -------------------------------------------------------------------------------- /Best Practice Topics on hold/bp-all-about-the-data.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Focus on resources, not APIs 4 | parent: Best practices 5 | nav_order: 9 6 | --- 7 | 8 | # Design: Focus on the resources, not the API operations 9 | {: .no_toc } 10 | In most consumer-facing applications, permissions should be modeled around the resources used by the application. For example, a file sharing application might represent permissions as actions that can be performed on a file or folder. This is a good, simple model that abstracts away the underlying implementation and the supporting service API operations. 11 | 12 | In contrast, some types of applications, particularly web services, frequently design permissions around the API operations themselves. For example, if a web service provided an API named `createThing()`, the authorization model would define a corresponding action named `createThing`. This works in many situations and makes it easy to understand the permissions; to invoke `createThing` operation, you need the `createThing` action permission. 13 | However, there are circumstances in which this API-centric approach is less than optimal. This is because the API operations are merely proxies for what customers truly want to protect: the underlying data and resources. If multiple API operations control access to the same resources, it can become difficult for administrators to reason about the many paths through which users can access the resources, and manage that access accordingly. 14 | 15 | To illustrate, consider a user directory holding the members of an organization. Users can be organized into groups, and one of the security goals is to prohibit discovery of group memberships by unauthorized parties. This service provides two API operations: 16 | 17 | + `listMembersOfGroup` 18 | + `listGroupMembershipsForUser` 19 | 20 | Both operations enable a user to discover group membership, so the permissions administrator must remember to coordinate access to both of them. Further compounding the difficulty, the service may later decide to release a new API to address more use cases, such as the following: 21 | 22 | + `isUserInGroups` – a new API to quickly test if a user belongs in one or more groups 23 | 24 | From a security perspective, this new API has opened a 3rd path to discover group memberships, thereby disrupting the carefully crafted permissions of the administrator. 25 | Instead, we recommend that you move from an API focused to a resource focused authorization model. The resource focused approach ignores the API semantics and focuses on the underlying data and common operations. Applying this approach to the group membership example would lead to an abstract permission, such as `viewGroupMembership`, which each API would invoke. 26 | 27 | | API name | Permissions | 28 | | --- |--- | 29 | | `listMembersOfGroup` | Requires `viewGroupMembership` permission on the user directory | 30 | | `listGroupMembershipsForUser` | Requires `viewGroupMembership` permission on the user directory | 31 | | `isUserInGroups` | Requires `viewGroupMembership` permission on the user directory | 32 | 33 | By defining this one permission, an administrator can successfully control access to the discovery of group membership. As a tradeoff, each API must now document the permissions it enforces, and an administrator must consult this documentation when crafting permissions. This can be a valid tradeoff when necessary to meet a customer’s security expectations. 34 | -------------------------------------------------------------------------------- /Best Practice Topics on hold/bp-fine-grained-perms.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Design fine-grained permissions 4 | parent: Best practices 5 | nav_order: 10 6 | --- 7 | 8 | # Design: Prefer fine-grained permissions in the model, broader permissions in the user interface 9 | {: .no_toc } 10 | One common regret in designing an application's authorization model is to start with very course-grained actions, such as `Read` and `Write`, and then retroactively realize that finer-grained actions are necessary. The need for finer-granularity can be driven by customer feedback for more granular access controls, or by compliance and security auditors who encourage least-privilege permissions. 11 | 12 | If fine-grained permissions are not defined upfront, it can require a complicated migration to convert the application code and policy statements to use a different, finer-grained set of permissions. For example, application code that previously authorized against a course-grained action will need to be modified to use the fine-grained actions. In addition, policies must be updated to reflect the migration, for example: 13 | 14 | ```cedar 15 | permit ( 16 | principal == User::"6688f676-1aa9-456a-acf4-228340b54e9d", 17 | action in [Action::"listFolderContents", Action::"viewFile"], 18 | //OLD - action with coarse-grained permissions 19 | //action == Action::"read", 20 | resource in Account::"c863f89b-461f-4fc2-b638-e5fa5f79a48b" 21 | ); 22 | ``` 23 | 24 | To avoid this costly migration, it is beneficial to define fine-grained permissions upfront. However, this presents another tradeoff if end-users are subsequently forced to understand a large number of fine-grained permissions, especially if most customers would be satisfied with course-grained controls such as `Read` and `Write`. To attain the best of both scenarios, fine-grained permissions can be aggregated into predefined groups such as `Read` and `Write` using mechanisms like policy templates or action groups. By using such mechanisms, customers can see the course-grained permissions. But, behind the scenes, the application is future-proofed by modeling the course-grained permissions as a collection of fine-grained actions. When either customers or auditors ask for it, the fine-grained permissions can be exposed. 25 | 26 | As an example, the following schema snippet creates an action group that consists of multiple actions in a group called `security`. 27 | 28 | ```json 29 | "actions": { 30 | "unlock": { 31 | "memberOf": [ { "id": "security" } ] 32 | }, 33 | "lock": { 34 | "memberOf": [ { "id": "security" } ] 35 | }, 36 | "security": {} 37 | } 38 | ``` 39 | 40 | You can then reference that group of `security` actions as a single element in a policy by using syntax like the following. 41 | 42 | ```cedar 43 | permit ( 44 | principal, 45 | action in Action::"security", 46 | resource 47 | ); 48 | 49 | ``` 50 | -------------------------------------------------------------------------------- /Best Practice Topics on hold/bp-group-vs-attribute.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Using groups compared to attributes 4 | parent: Best practices 5 | nav_order: 5 6 | --- 7 | 8 | # Tip: Choosing between group-based or attributes-based access control 9 | {: .no_toc } 10 | Consider a file-sharing application that wishes to grant access based on file type, such as giving access to view JPEG files, but not other file types. 11 | 12 | Would this be best achieved by labeling each file with an attribute named `fileType`, or by adding the files to a group named `jpegFiles` that represents the collection? 13 | 14 | Using an attribute supports policies like the following: 15 | 16 | ```cedar 17 | permit ( 18 | principal == User::"5a250ea5-89bb-4b07-9a97-c8632e876124", // "alice" 19 | action == Action::"readFile", 20 | resource 21 | ) 22 | when { 23 | resource.fileType == "JPEG" 24 | }; 25 | ``` 26 | 27 | Using a group supports policies like the following: 28 | 29 | ```cedar 30 | permit ( 31 | principal == User::"5a250ea5-89bb-4b07-9a97-c8632e876124", // "alice" 32 | action == Action::"readFile", 33 | resource in FileCollection::"39537fd1-da04-488e-8d37-65f4582ffb69" //"JPEG Files" 34 | ); 35 | ``` 36 | 37 | In this example, it might not make a significant difference and the choice is down to user preferences. However, in other situations, there are distinct benefits to one approach over the other. 38 | 39 | Attribute-based policies are helpful when the conditional expressions may be more complicated than simply checking equality. Imagine if the goal was to instead grant access to files under a certain size: 40 | 41 | ```cedar 42 | permit ( 43 | principal == User::"5a250ea5-89bb-4b07-9a97-c8632e876124", // "alice" 44 | action == Action::"readFile", 45 | resource 46 | ) 47 | when { 48 | resource.fileSizeBytes <= 1000000 49 | }; 50 | ``` 51 | 52 | The attribute-based approach fits naturally with conditional expressions, but would require more effort to achieve using groups. It would necessitate knowing which conditional expressions will be written and to construct groups representing those conditions, such as `Files_under_1MB`. 53 | 54 | In contrast, group-based policies are helpful when the resources might be organized into collections with inheritance of permissions. 55 | 56 | ![\[Illustrates a hierarchy of folders and files.\]](images/hierarchy.png) 57 | 58 | This organizational approach fits naturally with group-based policies. Another benefit of using groups is that it’s possible to iterate over the policies attached to a principal and determine which resource groups they have access to. This can be useful if an application wishes to render an interface that displays this information to end-users. 59 | 60 | Getting the same behavior by using attributes would require attaching an attribute to the resource that contains the transitive closure of all parent folders. Although it's possible, it's a less natural fit and harder to do correctly as folders are added, removed, or rearranged. 61 | 62 | In the end, both approaches are valid, and the choice often comes down to whatever most naturally aligns with the application's interface. For example, if end users see resources organized into hierarchical collections, then reflecting that in the Cedar authorization model is the most natural fit. In contrast, if end users see resources with arbitrary attributes and can write arbitrary rules for access management, then the attribute-based approach would most naturally align with the application's interface. 63 | -------------------------------------------------------------------------------- /Best Practice Topics on hold/bp-minimize-number-of-entities.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Minimize number of entity types 4 | parent: Best practices 5 | nav_order: 4 6 | --- 7 | 8 | # Best practice: Minimize the number of entity types 9 | 10 | {: .no_toc } 11 | 12 | Entity types in Cedar are similar to concepts in other programming languages such as `class` or `struct`. They define the particular shape of something. For example, this guide has references sample types with names such as “User”, “File”, “Photo”, and so on. 13 | 14 | The addition of new entity types to an application increases the complexity of the application's authorization model. This means, for example, that a new entity type can imply new resource types and new actions. It can also mean new types of principals. From the perspective of customers, auditors, security engineers, and others with a desire to deeply understand and inspect the authorization properties of an application, the creation of entity types increases the surface area for inspection. This increase can be regarded as a significant change to an application’s risk model. Entity types should be introduced when this change is justified, such as when launching new features and capabilities. 15 | 16 | Avoid a proliferation of entity types for other purposes. For example, Entity types should not be used as a resource-isolation mechanism by defining types such as `Account1`, `Account2`, and so on. Resource isolation can be achieved through other means, such as by using namespaces. 17 | 18 | A common practice when choosing the granularity of an entity type is to correlate one-to-one with the source authorities. This reflects the fact that entities are often pre-existing concepts in an application, already defined and managed by existing software. These existing concepts are typically evident in data models, API definitions, source code, and so on. The lowest friction path to bring these concepts into a Cedar authorization model is to represent them as they already exist in the application , perhaps with filtering and normalization on attributes to construct a clean basis for authorization. 19 | -------------------------------------------------------------------------------- /Best Practice Topics on hold/bp-permissions-in-attributes.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Don't embed permissions in attributes 4 | parent: Best practices 5 | nav_order: 4 6 | --- 7 | 8 | # Best practice: Avoid embedding permissions inside attributes 9 | {: .no_toc } 10 | 11 | Attributes are best used as an *input* to the authorization decision. Don't use attributes to represent the permissions themselves, such as by declaring an attribute named “permittedFolders” on a User: 12 | 13 | ```json 14 | // ANTI-PATTERN: commingling permissions into user attributes 15 | { 16 | "id": "df82e4ad-949e-44cb-8acf-2d1acda71798", 17 | "name": "alice", 18 | "email": "alice@example.com", 19 | "permittedFolders": [ 20 | "Folder::\"c943927f-d803-4f40-9a53-7740272cb969\"", 21 | "Folder::\"661817a9-d478-4096-943d-4ef1e082d19a\"", 22 | "Folder::\"b8ee140c-fa09-46c3-992e-099438930894\"" 23 | ] 24 | } 25 | ``` 26 | 27 | And, subsequently using the attribute within a policy: 28 | 29 | ```cedar 30 | // ANTI-PATTERN 31 | permit ( 32 | principal, 33 | action == Action::"readFile", 34 | resource 35 | ) 36 | when { 37 | resource in principal.permittedFolders 38 | }; 39 | ``` 40 | 41 | This approach transforms what would otherwise be a simple authorization model, where a specific principal has access to a specific folder, into an attributes-based access control (ABAC) model with the accompanying tradeoffs. One such tradeoff is that it becomes more difficult to quickly determine who has permission to a resource. In the preceding example, to determine who has access to a particular folder, it is necessary to iterate over every user to check if that folder is listed in their attributes, and doing so with the special awareness that there is a policy that grants access when they do. 42 | 43 | Another risk with this approach is the scaling factors when permissions are packed together inside a single `User` record. If the user has access to many things, the cumulative size of their `User` record will grow and perhaps approach the maximum limit of whatever system is storing the data. 44 | 45 | Instead, we recommend that you represent this scenario using multiple individual policies, perhaps using policy templates to minimize repetition. 46 | 47 | ```//BETTER PATTERN 48 | permit ( 49 | principal == User::"df82e4ad-949e-44cb-8acf-2d1acda71798", 50 | action == Action::"readFile", 51 | resource in Folder::"c943927f-d803-4f40-9a53-7740272cb969" 52 | ); 53 | 54 | permit ( 55 | principal == User::"df82e4ad-949e-44cb-8acf-2d1acda71798", 56 | action == Action::"readFile", 57 | resource in Folder::"661817a9-d478-4096-943d-4ef1e082d19a" 58 | ); 59 | 60 | permit ( 61 | principal == User::"df82e4ad-949e-44cb-8acf-2d1acda71798", 62 | action == Action::"readFile", 63 | resource in Folder::"b8ee140c-fa09-46c3-992e-099438930894" 64 | ); 65 | ``` 66 | 67 | Cedar can efficiently handle many individual, fine-grained policies during authorization evaluation. Modeling things in this way is more manageable and auditable over time. 68 | -------------------------------------------------------------------------------- /Best Practice Topics on hold/bp-resource-lives-in-container.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Every resource lives in a container 4 | parent: Best practices 5 | nav_order: 5 6 | --- 7 | 8 | # Design: Every resource lives in a container 9 | 10 | {: .no_toc } 11 | 12 | When designing an authorization model, you must associate every action with a particular resource. With an action such as `viewFile`, the resource that it applies to is intuitive; it applies to an individual file, or perhaps to a collection of files within a folder. However, an operation such as `createFile` can be less intuitive. When modeling the capability to create a file, what is the resource the action applies to? It cannot be the file itself, because the file doesn’t exist yet. 13 | 14 | This is an example of the generalized problem of resource creation. Resource creation is a bootstrapping problem, in that there must be a way for something to have permission to create resources even when no resources exist yet. The path to solving it is to recognize that every resource must exist within some container, and it is the container itself that acts as the anchor point for permissions. For example, if a folder pre-existed in the system, the ability to create a file can be modeled as a permission on that folder, since that is the location where permissions are necessary to instantiate the new resource. 15 | 16 | ```cedar 17 | permit ( 18 | principal == User::"&ExampleGuid1;", 19 | action == Action::"createFile", 20 | resource == Folder::"&ExampleGuid2;" 21 | ); 22 | ``` 23 | 24 | However, what if no folder exists yet? Perhaps this is a new customer account in an application where no resources exist yet. In this situation, there is still a context that can be intuitively understood by asking: where can the customer create new files? Most likely, they shouldn’t be able to create files inside any random customer account. Rather, there is an implied context, and that context is the customer’s own account boundary. Therefore, the account represents the container for resource creation, and this can be explicitly modeled in a policy similar to the following example. 25 | 26 | ```cedar 27 | // Grants permission to create files within an account, 28 | // or within any sub-folder inside the account. 29 | permit ( 30 | principal == User::"a1b2c3d4-e5f6-a1b2-c3d4-EXAMPLE11111", 31 | action == Action::"createFile", 32 | resource in Account::"a1b2c3d4-e5f6-a1b2-c3d4-EXAMPLE22222" 33 | ); 34 | ``` 35 | 36 | However, what if no accounts exist either? Perhaps we need to grant a software process that implements the customer sign-up workflow the ability to launch new accounts in the system. If so, we’ll need a container to hold the outermost boundary in which accounts can be launched. This root level container represents the system as a whole and might be named something like “system root” (although the decision of whether this is needed, and how to name it, is up to each application owner). 37 | 38 | 39 | 40 | ![\[Sample hierarchy of containers up to accounts and a system root.\]](images/resource-lives-in-container.png) 41 | 42 | This is one sample hierarchy. Others are valid as well. The important point is that resource creation always happens within the context of a resource container. Often, these containers are implicit, such as an account boundary, and therefore it can be easy to overlook them. When designing your authorization model, you’ll want to note these implicit assumptions so they can be formally documented and represented in the authorization model. 43 | -------------------------------------------------------------------------------- /Best Practice Topics on hold/bp-separate-principals-from-resource-containers.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Separate principals from resources 4 | parent: Best practices 5 | nav_order: 6 6 | --- 7 | 8 | # Design: Separate the principals from the resource containers 9 | 10 | {: .no_toc } 11 | 12 | When designing a resource hierarchy, one of the common inclinations (especially for consumer-facing applications) is to use the customer identity as the container for resources within a customer account. 13 | 14 | 15 | 16 | ![\[Sample hierarchy resources contained by a principal.\]](images/separate-principals-from-resources.png) 17 | 18 | This tends to be an anti-pattern as applications grow larger and more complex. This is because there is a natural tendency in richer applications to delegate access to additional users. Such a need may arise with the introduction of family accounts, for example, where other users can share account resources. Or, with enterprise customers who wish to designate multiple members of the workforce who can operate portions of the account. Alternatively, customers may want to transfer ownership of an account to a different user, or merge the resources of multiple accounts together. 19 | 20 | When a user identity acts as the account container, it can make these scenarios difficult to achieve. More alarming, if others are granted access to the account container in this approach, they may inadvertently be granted access to modify the user identity itself, such as changing Jane’s email or login credentials. 21 | 22 | Therefore, when possible to do so, a more resilient approach is to separate the principals from the resource containers, and model the connection between them via concepts such as “admin permissions” or “ownership”. 23 | 24 | 25 | 26 | ![\[Principals are separate from accounts that contain resources.\]](images/separate-principals-from-resources-2.png) 27 | 28 | For existing applications that are unable to pursue this decoupled model, we recommend that you consider mimicking it as much as possible when designing an authorization model. For example, an application that possesses only a single concept named `Customer` which encapsulates the user identity, login credentials, and the resources they own, could map this to an authorization model that contains one logical entity for `Customer Identity` (containing name, email, etc) and another for `Customer Resources`. This second container can then act as the parent node for all of the resources the user owns. Both entities might share the same Id, but have different entity types. 29 | 30 | 31 | 32 | ![\[Example showing deliberate decoupling of principals and resources.\]](images/separate-principals-from-resources-3.png) 33 | -------------------------------------------------------------------------------- /Best Practice Topics on hold/bp-transitive-attributes.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Transitive attributes 4 | parent: Best practices 5 | nav_order: 7 6 | --- 7 | 8 | # Tip: Modeling transitive attributes 9 | {: .no_toc } 10 | 11 | The decision between group-based or attribute-based access controls isn’t always a clear-cut dichotomy. Sometimes, it is helpful to combine both. To illustrate, consider a tree-based filesystem in which a parent folder can be labeled with an attribute such as `"visibility": "public"` that should transitively apply to all files contained within the folder: 12 | 13 | 16 | 17 | ![\[Entities in a hierarchy automatically inherit the parent entity's attributes.\]](images/transitive-attributes.png) 18 | 19 | Because the attribute from the parent entity is inherited by the child entity, you can express policies like the following example. 20 | 21 | ```cedar 22 | permit ( 23 | principal, 24 | action == Action::"readFile", 25 | resource 26 | ) 27 | when { 28 | // This works because the attribute value from the parent Folder is transitively 29 | // applied to individual Files within the Folder. 30 | resource.visibility == "public" 31 | }; 32 | ``` 33 | 34 | You might then ask the question "How are attribute values propagated across a hierarchy? Who does the propagation, when, and how?" The answer is that this is the role of the code that generates the who provides details about the entities to the authorization API. Recall that the entity information contains extra information about entities needed by the authorization evaluator. The extra information includes the parent-child relationships, the entity attributes, and whether to copy attribute values from a parent and inject them into child entities. 35 | 36 | However, supporting transitive attributes can introduce complexity. One of the situations to watch for is conflicts across the inheritance space, such as nested folders, where one parent overrides the value inherited from its own parent. You have to choose whether to allow inheritance in a situation like this, and set rules that determine which attribute value is ultimately inherited by the child entity. 37 | 38 | 39 | 40 | ![\[Decision about inheriting an attribute from conflicting parents.\]](images/transitive-attributes-2.png) 41 | 42 | Similarly, applications that allow inheritance from multiple parents at the same level must also consider conflicting values. 43 | 44 | 45 | 46 | ![\[Decision about inheriting from conflicting multiple parents.\]](images/transitive-attributes-3.png) 47 | 48 | The conflict resolution logic is an application-specific decision that depends upon the meaning of the attributes and the expectations that customers would have within the application. 49 | 50 | While these risks are important to consider, attribute propagation remains a valid and frequently useful tool to simplify policy management, especially in situations where conflicts can be minimized and therefore the inheritance rules become trivial. 51 | -------------------------------------------------------------------------------- /NOTICE: -------------------------------------------------------------------------------- 1 | Copyright Cedar Contributors 2 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ## Documentation for the Cedar Policy Language 2 | 3 | This repository hosts the markdown source files for the Cedar Policy Language Reference Guide. 4 | 5 | Current live site: https://docs.cedarpolicy.com 6 | 7 | ## We want your feedback about this documentation 8 | Our goal is to help you get everything you can from Cedar. If this guide helps you to do that, then let us know. If the guide isn't helping you, then we want to hear from you so we can address the issue. Submit a [GitHub issue](https://github.com/cedar-policy/cedar-docs/issues) or submit a [pull request](https://github.com/cedar-policy/cedar-docs/pulls). That sends your comments directly to the writers of this guide. We review every submission, looking for opportunities to improve the documentation. Thank you in advance for your help! 9 | 10 | ## Guidelines for contributing 11 | 12 | Thank you for your interest in contributing to the Cedar documentation! We greatly value feedback and contributions from our community. 13 | 14 | Please read through this document before you submit any pull requests or issues. It will help us work together more effectively. 15 | 16 | ### What to expect when you contribute 17 | 18 | When you submit a pull request, our team is notified and will respond as quickly as we can. We'll do our best to work with you to ensure that your pull request adheres to our style and standards. If we merge your pull request, we might make additional edits later for style or clarity. 19 | 20 | We look forward to receiving your pull requests for: 21 | 22 | * New content you'd like to contribute (such as new code samples or tutorials) 23 | * Inaccuracies in the content 24 | * Information gaps in the content that need more detail to be complete 25 | * Typos or grammatical errors 26 | * Suggested rewrites that improve clarity and reduce confusion 27 | 28 | **Note:** We all write differently, and you might not like how we've written or organized something currently. We want that feedback. But please be sure that your request for a rewrite is supported by the previous criteria. If it isn't, we might decline to merge it. 29 | 30 | ### How to contribute 31 | 32 | To contribute, send us a pull request. For small changes, such as fixing a typo or adding a link, you can use the [GitHub Edit Button](https://blog.github.com/2011-04-26-forking-with-the-edit-button/). For larger changes: 33 | 34 | 1. [Fork the repository](https://help.github.com/articles/fork-a-repo/). 35 | 2. In your fork, make your change in a branch that's based on this repo's **main** branch. 36 | 3. Commit the change to your fork, using a clear and descriptive commit message. 37 | 4. [Create a pull request](https://help.github.com/articles/creating-a-pull-request-from-a-fork/), answering any questions in the pull request form. 38 | 39 | Before you send us a pull request, please be sure that: 40 | 41 | 1. You're working from the latest source on the **main** branch. 42 | 2. You check [existing open](https://github.com/cedar-policy/cedar-docs/pulls), and [recently closed](https://github.com/cedar-policy/cedar-docs/pulls?q=is%3Apr+is%3Aclosed), pull requests to be sure that someone else hasn't already addressed the problem. 43 | 3. You [create an issue](https://github.com/cedar-policy/cedar-docs/issues/new) before working on a contribution that will take a significant amount of your time. 44 | 45 | For contributions that will take a significant amount of time, [open a new issue](https://github.com/cedar-policy/cedar-docs/issues/new) to pitch your idea before you get started. Explain the problem and describe the content you want to see added to the documentation. Let us know if you'll write it yourself or if you'd like us to help. We'll discuss your proposal with you and let you know whether we're likely to accept it. We don't want you to spend a lot of time on a contribution that might be outside the scope of the documentation or that's already in the works. 46 | 47 | ### Finding contributions to work on 48 | 49 | If you'd like to contribute, but don't have a project in mind, look at the [open issues](https://github.com/cedar-policy/cedar-docs/issues) in this repository for some ideas. Any issues with the [help wanted](https://github.com/cedar-policy/cedar-docs/labels/help%20wanted) or [enhancement](https://github.com/cedar-policy/cedar-docs/labels/enhancement) labels are a great place to start. 50 | 51 | In addition to written content, we really appreciate new examples and code samples for our documentation, such as examples for different platforms or environments, and code samples in additional languages. 52 | 53 | ## Code of conduct 54 | 55 | This project has adopted the [Amazon Open Source Code of Conduct](https://aws.github.io/code-of-conduct). For more information, see the [Code of Conduct FAQ](https://aws.github.io/code-of-conduct-faq) or contact [opensource-codeofconduct@amazon.com](mailto:opensource-codeofconduct@amazon.com) with any additional questions or comments. 56 | 57 | ## Security issue notifications 58 | 59 | If you discover a potential security issue, please notify AWS Security via our [vulnerability reporting page](http://aws.amazon.com/security/vulnerability-reporting/). Please do **not** create a public issue on GitHub. 60 | 61 | ## License 62 | 63 | This project is licensed under the Apache-2.0 License. See the [LICENSE](https://github.com/cedar-policy/cedar-docs/blob/main/LICENSE) file for this project's licensing. We will ask you to confirm the licensing of your contribution. We may ask you to sign a [Contributor License Agreement (CLA)](http://en.wikipedia.org/wiki/Contributor_License_Agreement) for larger changes. 64 | 65 | 66 | 67 | -------------------------------------------------------------------------------- /docs/.markdownlint.yaml: -------------------------------------------------------------------------------- 1 | # Default state for all rules 2 | default: true 3 | 4 | MD013: false 5 | 6 | MD022: false 7 | 8 | MD033: false -------------------------------------------------------------------------------- /docs/404.html: -------------------------------------------------------------------------------- 1 | --- 2 | permalink: /404.html 3 | layout: default 4 | --- 5 | 6 | 19 | 20 |
21 |

404

22 | 23 |

Page not found :(

24 |

The requested page could not be found.

25 |
26 | -------------------------------------------------------------------------------- /docs/CNAME: -------------------------------------------------------------------------------- 1 | docs.cedarpolicy.com -------------------------------------------------------------------------------- /docs/Gemfile: -------------------------------------------------------------------------------- 1 | source "https://rubygems.org" 2 | # Hello! This is where you manage which Jekyll version is used to run. 3 | # When you want to use a different version, change it below, save the 4 | # file and run `bundle install`. Run Jekyll with `bundle exec`, like so: 5 | # 6 | # bundle exec jekyll serve 7 | # 8 | # This will help ensure the proper Jekyll version is running. 9 | # Happy Jekylling! 10 | #gem "jekyll", "~> 4.3.2" 11 | # This is the default theme for new Jekyll sites. You may change this to anything you like. 12 | gem "minima", "~> 2.5" 13 | # If you want to use GitHub Pages, remove the "gem "jekyll"" above and 14 | # uncomment the line below. To upgrade, run `bundle update github-pages`. 15 | gem "github-pages", "~> 228", group: :jekyll_plugins 16 | # If you have any plugins, put them here! 17 | group :jekyll_plugins do 18 | gem "jekyll-feed", "~> 0.12" 19 | end 20 | 21 | # Windows and JRuby does not include zoneinfo files, so bundle the tzinfo-data gem 22 | # and associated library. 23 | platforms :mingw, :x64_mingw, :mswin, :jruby do 24 | gem "tzinfo", ">= 1", "< 3" 25 | gem "tzinfo-data" 26 | end 27 | 28 | # Performance-booster for watching directories on Windows 29 | gem "wdm", "~> 0.1.1", :platforms => [:mingw, :x64_mingw, :mswin] 30 | 31 | # Lock `http_parser.rb` gem to `v0.6.x` on JRuby builds since newer versions of the gem 32 | # do not have a Java counterpart. 33 | gem "http_parser.rb", "~> 0.6.0", :platforms => [:jruby] 34 | 35 | gem "webrick", "~> 1.8" 36 | 37 | gem "minitest", "~> 5.19.0" 38 | 39 | 40 | # Add Jekyll default layout - 3/28 jitani 41 | gem "jekyll-default-layout" 42 | -------------------------------------------------------------------------------- /docs/Gemfile.lock: -------------------------------------------------------------------------------- 1 | GEM 2 | remote: https://rubygems.org/ 3 | specs: 4 | activesupport (7.0.7.2) 5 | concurrent-ruby (~> 1.0, >= 1.0.2) 6 | i18n (>= 1.6, < 2) 7 | minitest (>= 5.1) 8 | tzinfo (~> 2.0) 9 | addressable (2.8.5) 10 | public_suffix (>= 2.0.2, < 6.0) 11 | coffee-script (2.4.1) 12 | coffee-script-source 13 | execjs 14 | coffee-script-source (1.11.1) 15 | colorator (1.1.0) 16 | commonmarker (0.23.10) 17 | concurrent-ruby (1.2.2) 18 | dnsruby (1.70.0) 19 | simpleidn (~> 0.2.1) 20 | em-websocket (0.5.3) 21 | eventmachine (>= 0.12.9) 22 | http_parser.rb (~> 0) 23 | ethon (0.16.0) 24 | ffi (>= 1.15.0) 25 | eventmachine (1.2.7) 26 | execjs (2.8.1) 27 | faraday (2.7.10) 28 | faraday-net_http (>= 2.0, < 3.1) 29 | ruby2_keywords (>= 0.0.4) 30 | faraday-net_http (3.0.2) 31 | ffi (1.15.5) 32 | forwardable-extended (2.6.0) 33 | gemoji (3.0.1) 34 | github-pages (228) 35 | github-pages-health-check (= 1.17.9) 36 | jekyll (= 3.9.3) 37 | jekyll-avatar (= 0.7.0) 38 | jekyll-coffeescript (= 1.1.1) 39 | jekyll-commonmark-ghpages (= 0.4.0) 40 | jekyll-default-layout (= 0.1.4) 41 | jekyll-feed (= 0.15.1) 42 | jekyll-gist (= 1.5.0) 43 | jekyll-github-metadata (= 2.13.0) 44 | jekyll-include-cache (= 0.2.1) 45 | jekyll-mentions (= 1.6.0) 46 | jekyll-optional-front-matter (= 0.3.2) 47 | jekyll-paginate (= 1.1.0) 48 | jekyll-readme-index (= 0.3.0) 49 | jekyll-redirect-from (= 0.16.0) 50 | jekyll-relative-links (= 0.6.1) 51 | jekyll-remote-theme (= 0.4.3) 52 | jekyll-sass-converter (= 1.5.2) 53 | jekyll-seo-tag (= 2.8.0) 54 | jekyll-sitemap (= 1.4.0) 55 | jekyll-swiss (= 1.0.0) 56 | jekyll-theme-architect (= 0.2.0) 57 | jekyll-theme-cayman (= 0.2.0) 58 | jekyll-theme-dinky (= 0.2.0) 59 | jekyll-theme-hacker (= 0.2.0) 60 | jekyll-theme-leap-day (= 0.2.0) 61 | jekyll-theme-merlot (= 0.2.0) 62 | jekyll-theme-midnight (= 0.2.0) 63 | jekyll-theme-minimal (= 0.2.0) 64 | jekyll-theme-modernist (= 0.2.0) 65 | jekyll-theme-primer (= 0.6.0) 66 | jekyll-theme-slate (= 0.2.0) 67 | jekyll-theme-tactile (= 0.2.0) 68 | jekyll-theme-time-machine (= 0.2.0) 69 | jekyll-titles-from-headings (= 0.5.3) 70 | jemoji (= 0.12.0) 71 | kramdown (= 2.3.2) 72 | kramdown-parser-gfm (= 1.1.0) 73 | liquid (= 4.0.4) 74 | mercenary (~> 0.3) 75 | minima (= 2.5.1) 76 | nokogiri (>= 1.13.6, < 2.0) 77 | rouge (= 3.26.0) 78 | terminal-table (~> 1.4) 79 | github-pages-health-check (1.17.9) 80 | addressable (~> 2.3) 81 | dnsruby (~> 1.60) 82 | octokit (~> 4.0) 83 | public_suffix (>= 3.0, < 5.0) 84 | typhoeus (~> 1.3) 85 | html-pipeline (2.14.3) 86 | activesupport (>= 2) 87 | nokogiri (>= 1.4) 88 | http_parser.rb (0.8.0) 89 | i18n (1.14.1) 90 | concurrent-ruby (~> 1.0) 91 | jekyll (3.9.3) 92 | addressable (~> 2.4) 93 | colorator (~> 1.0) 94 | em-websocket (~> 0.5) 95 | i18n (>= 0.7, < 2) 96 | jekyll-sass-converter (~> 1.0) 97 | jekyll-watch (~> 2.0) 98 | kramdown (>= 1.17, < 3) 99 | liquid (~> 4.0) 100 | mercenary (~> 0.3.3) 101 | pathutil (~> 0.9) 102 | rouge (>= 1.7, < 4) 103 | safe_yaml (~> 1.0) 104 | jekyll-avatar (0.7.0) 105 | jekyll (>= 3.0, < 5.0) 106 | jekyll-coffeescript (1.1.1) 107 | coffee-script (~> 2.2) 108 | coffee-script-source (~> 1.11.1) 109 | jekyll-commonmark (1.4.0) 110 | commonmarker (~> 0.22) 111 | jekyll-commonmark-ghpages (0.4.0) 112 | commonmarker (~> 0.23.7) 113 | jekyll (~> 3.9.0) 114 | jekyll-commonmark (~> 1.4.0) 115 | rouge (>= 2.0, < 5.0) 116 | jekyll-default-layout (0.1.4) 117 | jekyll (~> 3.0) 118 | jekyll-feed (0.15.1) 119 | jekyll (>= 3.7, < 5.0) 120 | jekyll-gist (1.5.0) 121 | octokit (~> 4.2) 122 | jekyll-github-metadata (2.13.0) 123 | jekyll (>= 3.4, < 5.0) 124 | octokit (~> 4.0, != 4.4.0) 125 | jekyll-include-cache (0.2.1) 126 | jekyll (>= 3.7, < 5.0) 127 | jekyll-mentions (1.6.0) 128 | html-pipeline (~> 2.3) 129 | jekyll (>= 3.7, < 5.0) 130 | jekyll-optional-front-matter (0.3.2) 131 | jekyll (>= 3.0, < 5.0) 132 | jekyll-paginate (1.1.0) 133 | jekyll-readme-index (0.3.0) 134 | jekyll (>= 3.0, < 5.0) 135 | jekyll-redirect-from (0.16.0) 136 | jekyll (>= 3.3, < 5.0) 137 | jekyll-relative-links (0.6.1) 138 | jekyll (>= 3.3, < 5.0) 139 | jekyll-remote-theme (0.4.3) 140 | addressable (~> 2.0) 141 | jekyll (>= 3.5, < 5.0) 142 | jekyll-sass-converter (>= 1.0, <= 3.0.0, != 2.0.0) 143 | rubyzip (>= 1.3.0, < 3.0) 144 | jekyll-sass-converter (1.5.2) 145 | sass (~> 3.4) 146 | jekyll-seo-tag (2.8.0) 147 | jekyll (>= 3.8, < 5.0) 148 | jekyll-sitemap (1.4.0) 149 | jekyll (>= 3.7, < 5.0) 150 | jekyll-swiss (1.0.0) 151 | jekyll-theme-architect (0.2.0) 152 | jekyll (> 3.5, < 5.0) 153 | jekyll-seo-tag (~> 2.0) 154 | jekyll-theme-cayman (0.2.0) 155 | jekyll (> 3.5, < 5.0) 156 | jekyll-seo-tag (~> 2.0) 157 | jekyll-theme-dinky (0.2.0) 158 | jekyll (> 3.5, < 5.0) 159 | jekyll-seo-tag (~> 2.0) 160 | jekyll-theme-hacker (0.2.0) 161 | jekyll (> 3.5, < 5.0) 162 | jekyll-seo-tag (~> 2.0) 163 | jekyll-theme-leap-day (0.2.0) 164 | jekyll (> 3.5, < 5.0) 165 | jekyll-seo-tag (~> 2.0) 166 | jekyll-theme-merlot (0.2.0) 167 | jekyll (> 3.5, < 5.0) 168 | jekyll-seo-tag (~> 2.0) 169 | jekyll-theme-midnight (0.2.0) 170 | jekyll (> 3.5, < 5.0) 171 | jekyll-seo-tag (~> 2.0) 172 | jekyll-theme-minimal (0.2.0) 173 | jekyll (> 3.5, < 5.0) 174 | jekyll-seo-tag (~> 2.0) 175 | jekyll-theme-modernist (0.2.0) 176 | jekyll (> 3.5, < 5.0) 177 | jekyll-seo-tag (~> 2.0) 178 | jekyll-theme-primer (0.6.0) 179 | jekyll (> 3.5, < 5.0) 180 | jekyll-github-metadata (~> 2.9) 181 | jekyll-seo-tag (~> 2.0) 182 | jekyll-theme-slate (0.2.0) 183 | jekyll (> 3.5, < 5.0) 184 | jekyll-seo-tag (~> 2.0) 185 | jekyll-theme-tactile (0.2.0) 186 | jekyll (> 3.5, < 5.0) 187 | jekyll-seo-tag (~> 2.0) 188 | jekyll-theme-time-machine (0.2.0) 189 | jekyll (> 3.5, < 5.0) 190 | jekyll-seo-tag (~> 2.0) 191 | jekyll-titles-from-headings (0.5.3) 192 | jekyll (>= 3.3, < 5.0) 193 | jekyll-watch (2.2.1) 194 | listen (~> 3.0) 195 | jemoji (0.12.0) 196 | gemoji (~> 3.0) 197 | html-pipeline (~> 2.2) 198 | jekyll (>= 3.0, < 5.0) 199 | kramdown (2.3.2) 200 | rexml 201 | kramdown-parser-gfm (1.1.0) 202 | kramdown (~> 2.0) 203 | liquid (4.0.4) 204 | listen (3.8.0) 205 | rb-fsevent (~> 0.10, >= 0.10.3) 206 | rb-inotify (~> 0.9, >= 0.9.10) 207 | mercenary (0.3.6) 208 | minima (2.5.1) 209 | jekyll (>= 3.5, < 5.0) 210 | jekyll-feed (~> 0.9) 211 | jekyll-seo-tag (~> 2.1) 212 | minitest (5.19.0) 213 | nokogiri (1.18.8-x86_64-linux-gnu) 214 | racc (~> 1.4) 215 | octokit (4.25.1) 216 | faraday (>= 1, < 3) 217 | sawyer (~> 0.9) 218 | pathutil (0.16.2) 219 | forwardable-extended (~> 2.6) 220 | public_suffix (4.0.7) 221 | racc (1.8.1) 222 | rb-fsevent (0.11.2) 223 | rb-inotify (0.10.1) 224 | ffi (~> 1.0) 225 | rexml (3.3.9) 226 | rouge (3.26.0) 227 | ruby2_keywords (0.0.5) 228 | rubyzip (2.3.2) 229 | safe_yaml (1.0.5) 230 | sass (3.7.4) 231 | sass-listen (~> 4.0.0) 232 | sass-listen (4.0.0) 233 | rb-fsevent (~> 0.9, >= 0.9.4) 234 | rb-inotify (~> 0.9, >= 0.9.7) 235 | sawyer (0.9.2) 236 | addressable (>= 2.3.5) 237 | faraday (>= 0.17.3, < 3) 238 | simpleidn (0.2.1) 239 | unf (~> 0.1.4) 240 | terminal-table (1.8.0) 241 | unicode-display_width (~> 1.1, >= 1.1.1) 242 | typhoeus (1.4.0) 243 | ethon (>= 0.9.0) 244 | tzinfo (2.0.6) 245 | concurrent-ruby (~> 1.0) 246 | unf (0.1.4) 247 | unf_ext 248 | unf_ext (0.0.8.2) 249 | unicode-display_width (1.8.0) 250 | webrick (1.8.2) 251 | 252 | PLATFORMS 253 | x86_64-linux 254 | 255 | DEPENDENCIES 256 | github-pages (~> 228) 257 | http_parser.rb (~> 0.6.0) 258 | jekyll-default-layout 259 | jekyll-feed (~> 0.12) 260 | minima (~> 2.5) 261 | minitest (~> 5.19.0) 262 | tzinfo (>= 1, < 3) 263 | tzinfo-data 264 | wdm (~> 0.1.1) 265 | webrick (~> 1.8) 266 | 267 | BUNDLED WITH 268 | 2.4.19 269 | -------------------------------------------------------------------------------- /docs/Gemfile.orig: -------------------------------------------------------------------------------- 1 | GEM 2 | remote: https://rubygems.org/ 3 | specs: 4 | activesupport (7.0.7.2) 5 | concurrent-ruby (~> 1.0, >= 1.0.2) 6 | i18n (>= 1.6, < 2) 7 | minitest (>= 5.1) 8 | tzinfo (~> 2.0) 9 | addressable (2.8.5) 10 | public_suffix (>= 2.0.2, < 6.0) 11 | coffee-script (2.4.1) 12 | coffee-script-source 13 | execjs 14 | coffee-script-source (1.11.1) 15 | colorator (1.1.0) 16 | commonmarker (0.23.10) 17 | concurrent-ruby (1.2.2) 18 | dnsruby (1.70.0) 19 | simpleidn (~> 0.2.1) 20 | em-websocket (0.5.3) 21 | eventmachine (>= 0.12.9) 22 | http_parser.rb (~> 0) 23 | ethon (0.16.0) 24 | ffi (>= 1.15.0) 25 | eventmachine (1.2.7) 26 | execjs (2.8.1) 27 | faraday (2.7.10) 28 | faraday-net_http (>= 2.0, < 3.1) 29 | ruby2_keywords (>= 0.0.4) 30 | faraday-net_http (3.0.2) 31 | ffi (1.15.5) 32 | forwardable-extended (2.6.0) 33 | gemoji (3.0.1) 34 | github-pages (228) 35 | github-pages-health-check (= 1.17.9) 36 | jekyll (= 3.9.3) 37 | jekyll-avatar (= 0.7.0) 38 | jekyll-coffeescript (= 1.1.1) 39 | jekyll-commonmark-ghpages (= 0.4.0) 40 | jekyll-default-layout (= 0.1.4) 41 | jekyll-feed (= 0.15.1) 42 | jekyll-gist (= 1.5.0) 43 | jekyll-github-metadata (= 2.13.0) 44 | jekyll-include-cache (= 0.2.1) 45 | jekyll-mentions (= 1.6.0) 46 | jekyll-optional-front-matter (= 0.3.2) 47 | jekyll-paginate (= 1.1.0) 48 | jekyll-readme-index (= 0.3.0) 49 | jekyll-redirect-from (= 0.16.0) 50 | jekyll-relative-links (= 0.6.1) 51 | jekyll-remote-theme (= 0.4.3) 52 | jekyll-sass-converter (= 1.5.2) 53 | jekyll-seo-tag (= 2.8.0) 54 | jekyll-sitemap (= 1.4.0) 55 | jekyll-swiss (= 1.0.0) 56 | jekyll-theme-architect (= 0.2.0) 57 | jekyll-theme-cayman (= 0.2.0) 58 | jekyll-theme-dinky (= 0.2.0) 59 | jekyll-theme-hacker (= 0.2.0) 60 | jekyll-theme-leap-day (= 0.2.0) 61 | jekyll-theme-merlot (= 0.2.0) 62 | jekyll-theme-midnight (= 0.2.0) 63 | jekyll-theme-minimal (= 0.2.0) 64 | jekyll-theme-modernist (= 0.2.0) 65 | jekyll-theme-primer (= 0.6.0) 66 | jekyll-theme-slate (= 0.2.0) 67 | jekyll-theme-tactile (= 0.2.0) 68 | jekyll-theme-time-machine (= 0.2.0) 69 | jekyll-titles-from-headings (= 0.5.3) 70 | jemoji (= 0.12.0) 71 | kramdown (= 2.3.2) 72 | kramdown-parser-gfm (= 1.1.0) 73 | liquid (= 4.0.4) 74 | mercenary (~> 0.3) 75 | minima (= 2.5.1) 76 | nokogiri (>= 1.13.6, < 2.0) 77 | rouge (= 3.26.0) 78 | terminal-table (~> 1.4) 79 | github-pages-health-check (1.17.9) 80 | addressable (~> 2.3) 81 | dnsruby (~> 1.60) 82 | octokit (~> 4.0) 83 | public_suffix (>= 3.0, < 5.0) 84 | typhoeus (~> 1.3) 85 | html-pipeline (2.14.3) 86 | activesupport (>= 2) 87 | nokogiri (>= 1.4) 88 | http_parser.rb (0.8.0) 89 | i18n (1.14.1) 90 | concurrent-ruby (~> 1.0) 91 | jekyll (3.9.3) 92 | addressable (~> 2.4) 93 | colorator (~> 1.0) 94 | em-websocket (~> 0.5) 95 | i18n (>= 0.7, < 2) 96 | jekyll-sass-converter (~> 1.0) 97 | jekyll-watch (~> 2.0) 98 | kramdown (>= 1.17, < 3) 99 | liquid (~> 4.0) 100 | mercenary (~> 0.3.3) 101 | pathutil (~> 0.9) 102 | rouge (>= 1.7, < 4) 103 | safe_yaml (~> 1.0) 104 | jekyll-avatar (0.7.0) 105 | jekyll (>= 3.0, < 5.0) 106 | jekyll-coffeescript (1.1.1) 107 | coffee-script (~> 2.2) 108 | coffee-script-source (~> 1.11.1) 109 | jekyll-commonmark (1.4.0) 110 | commonmarker (~> 0.22) 111 | jekyll-commonmark-ghpages (0.4.0) 112 | commonmarker (~> 0.23.7) 113 | jekyll (~> 3.9.0) 114 | jekyll-commonmark (~> 1.4.0) 115 | rouge (>= 2.0, < 5.0) 116 | jekyll-default-layout (0.1.4) 117 | jekyll (~> 3.0) 118 | jekyll-feed (0.15.1) 119 | jekyll (>= 3.7, < 5.0) 120 | jekyll-gist (1.5.0) 121 | octokit (~> 4.2) 122 | jekyll-github-metadata (2.13.0) 123 | jekyll (>= 3.4, < 5.0) 124 | octokit (~> 4.0, != 4.4.0) 125 | jekyll-include-cache (0.2.1) 126 | jekyll (>= 3.7, < 5.0) 127 | jekyll-mentions (1.6.0) 128 | html-pipeline (~> 2.3) 129 | jekyll (>= 3.7, < 5.0) 130 | jekyll-optional-front-matter (0.3.2) 131 | jekyll (>= 3.0, < 5.0) 132 | jekyll-paginate (1.1.0) 133 | jekyll-readme-index (0.3.0) 134 | jekyll (>= 3.0, < 5.0) 135 | jekyll-redirect-from (0.16.0) 136 | jekyll (>= 3.3, < 5.0) 137 | jekyll-relative-links (0.6.1) 138 | jekyll (>= 3.3, < 5.0) 139 | jekyll-remote-theme (0.4.3) 140 | addressable (~> 2.0) 141 | jekyll (>= 3.5, < 5.0) 142 | jekyll-sass-converter (>= 1.0, <= 3.0.0, != 2.0.0) 143 | rubyzip (>= 1.3.0, < 3.0) 144 | jekyll-sass-converter (1.5.2) 145 | sass (~> 3.4) 146 | jekyll-seo-tag (2.8.0) 147 | jekyll (>= 3.8, < 5.0) 148 | jekyll-sitemap (1.4.0) 149 | jekyll (>= 3.7, < 5.0) 150 | jekyll-swiss (1.0.0) 151 | jekyll-theme-architect (0.2.0) 152 | jekyll (> 3.5, < 5.0) 153 | jekyll-seo-tag (~> 2.0) 154 | jekyll-theme-cayman (0.2.0) 155 | jekyll (> 3.5, < 5.0) 156 | jekyll-seo-tag (~> 2.0) 157 | jekyll-theme-dinky (0.2.0) 158 | jekyll (> 3.5, < 5.0) 159 | jekyll-seo-tag (~> 2.0) 160 | jekyll-theme-hacker (0.2.0) 161 | jekyll (> 3.5, < 5.0) 162 | jekyll-seo-tag (~> 2.0) 163 | jekyll-theme-leap-day (0.2.0) 164 | jekyll (> 3.5, < 5.0) 165 | jekyll-seo-tag (~> 2.0) 166 | jekyll-theme-merlot (0.2.0) 167 | jekyll (> 3.5, < 5.0) 168 | jekyll-seo-tag (~> 2.0) 169 | jekyll-theme-midnight (0.2.0) 170 | jekyll (> 3.5, < 5.0) 171 | jekyll-seo-tag (~> 2.0) 172 | jekyll-theme-minimal (0.2.0) 173 | jekyll (> 3.5, < 5.0) 174 | jekyll-seo-tag (~> 2.0) 175 | jekyll-theme-modernist (0.2.0) 176 | jekyll (> 3.5, < 5.0) 177 | jekyll-seo-tag (~> 2.0) 178 | jekyll-theme-primer (0.6.0) 179 | jekyll (> 3.5, < 5.0) 180 | jekyll-github-metadata (~> 2.9) 181 | jekyll-seo-tag (~> 2.0) 182 | jekyll-theme-slate (0.2.0) 183 | jekyll (> 3.5, < 5.0) 184 | jekyll-seo-tag (~> 2.0) 185 | jekyll-theme-tactile (0.2.0) 186 | jekyll (> 3.5, < 5.0) 187 | jekyll-seo-tag (~> 2.0) 188 | jekyll-theme-time-machine (0.2.0) 189 | jekyll (> 3.5, < 5.0) 190 | jekyll-seo-tag (~> 2.0) 191 | jekyll-titles-from-headings (0.5.3) 192 | jekyll (>= 3.3, < 5.0) 193 | jekyll-watch (2.2.1) 194 | listen (~> 3.0) 195 | jemoji (0.12.0) 196 | gemoji (~> 3.0) 197 | html-pipeline (~> 2.2) 198 | jekyll (>= 3.0, < 5.0) 199 | kramdown (2.3.2) 200 | rexml 201 | kramdown-parser-gfm (1.1.0) 202 | kramdown (~> 2.0) 203 | liquid (4.0.4) 204 | listen (3.8.0) 205 | rb-fsevent (~> 0.10, >= 0.10.3) 206 | rb-inotify (~> 0.9, >= 0.9.10) 207 | mercenary (0.3.6) 208 | minima (2.5.1) 209 | jekyll (>= 3.5, < 5.0) 210 | jekyll-feed (~> 0.9) 211 | jekyll-seo-tag (~> 2.1) 212 | minitest (5.19.0) 213 | nokogiri (1.15.4-x86_64-darwin) 214 | racc (~> 1.4) 215 | nokogiri (1.15.4-x86_64-linux) 216 | racc (~> 1.4) 217 | octokit (4.25.1) 218 | faraday (>= 1, < 3) 219 | sawyer (~> 0.9) 220 | pathutil (0.16.2) 221 | forwardable-extended (~> 2.6) 222 | public_suffix (4.0.7) 223 | racc (1.7.1) 224 | rb-fsevent (0.11.2) 225 | rb-inotify (0.10.1) 226 | ffi (~> 1.0) 227 | rexml (3.2.6) 228 | rouge (3.26.0) 229 | ruby2_keywords (0.0.5) 230 | rubyzip (2.3.2) 231 | safe_yaml (1.0.5) 232 | sass (3.7.4) 233 | sass-listen (~> 4.0.0) 234 | sass-listen (4.0.0) 235 | rb-fsevent (~> 0.9, >= 0.9.4) 236 | rb-inotify (~> 0.9, >= 0.9.7) 237 | sawyer (0.9.2) 238 | addressable (>= 2.3.5) 239 | faraday (>= 0.17.3, < 3) 240 | simpleidn (0.2.1) 241 | unf (~> 0.1.4) 242 | terminal-table (1.8.0) 243 | unicode-display_width (~> 1.1, >= 1.1.1) 244 | typhoeus (1.4.0) 245 | ethon (>= 0.9.0) 246 | tzinfo (2.0.6) 247 | concurrent-ruby (~> 1.0) 248 | unf (0.1.4) 249 | unf_ext 250 | unf_ext (0.0.8.2) 251 | unicode-display_width (1.8.0) 252 | webrick (1.8.1) 253 | 254 | PLATFORMS 255 | x86_64-darwin-21 256 | x86_64-linux 257 | 258 | DEPENDENCIES 259 | github-pages (~> 228) 260 | http_parser.rb (~> 0.6.0) 261 | jekyll-feed (~> 0.12) 262 | minima (~> 2.5) 263 | tzinfo (>= 1, < 3) 264 | tzinfo-data 265 | wdm (~> 0.1.1) 266 | webrick (~> 1.8) 267 | 268 | BUNDLED WITH 269 | 2.4.16 270 | -------------------------------------------------------------------------------- /docs/_config.yml: -------------------------------------------------------------------------------- 1 | # Site wide configuration 2 | 3 | title: Cedar Policy Language Reference Guide 4 | locale: en_US 5 | logo: images/Cedar1-green.png 6 | 7 | remote_theme: just-the-docs/just-the-docs 8 | plugins: 9 | - jekyll-remote-theme 10 | - jekyll-default-layout # 11 | 12 | # Add ref to awsstyle.scss 13 | color_scheme: awsstyle 14 | 15 | # GitHub edit and feedback links 16 | gh_edit_link: true # show or hide edit this page link 17 | gh_edit_link_text: "We welcome your feedback. You can edit this page on GitHub." 18 | gh_edit_repository: "https://github.com/cedar-policy/cedar-docs" # the github URL for your repo 19 | gh_edit_branch: "main" # the branch that your docs is served from 20 | gh_edit_source: "docs" # the source that your files originate from 21 | gh_edit_view_mode: "tree" # "tree" or "edit" if you want the user to jump into the editor immediately 22 | 23 | # Callouts 24 | callouts: 25 | note: 26 | title: Note 27 | color: blue 28 | important: 29 | title: Important 30 | color: yellow 31 | warning: 32 | title: Warning 33 | color: red 34 | 35 | enable_copy_code_button: true 36 | 37 | # Enter the following platform usernames if you would like for them to appear on your site. 38 | owner: 39 | name: Amazon Web Services (AWS) 40 | email: cedar-docs@amazon.com 41 | 42 | kramdown: 43 | syntax_highlighter_opts: 44 | disable : true 45 | 46 | collections_dir: collections 47 | 48 | collections: 49 | overview: 50 | output: true 51 | auth: 52 | output: true 53 | policies: 54 | output: true 55 | schema: 56 | output: true 57 | bestpractices: 58 | output: true 59 | other: 60 | output: true 61 | 62 | just_the_docs: 63 | collections: 64 | overview: 65 | name: Overview 66 | auth: 67 | name: Authorization requests 68 | policies: 69 | name: Policies 70 | schema: 71 | name: Schema 72 | bestpractices: 73 | name: Best practices 74 | other: 75 | name: Other 76 | -------------------------------------------------------------------------------- /docs/_config.yml.orig: -------------------------------------------------------------------------------- 1 | # Welcome to Jekyll! 2 | # 3 | # This config file is meant for settings that affect your whole blog, values 4 | # which you are expected to set up once and rarely edit after that. If you find 5 | # yourself editing this file very often, consider using Jekyll's data files 6 | # feature for the data you need to update frequently. 7 | # 8 | # For technical reasons, this file is *NOT* reloaded automatically when you use 9 | # 'bundle exec jekyll serve'. If you change this file, please restart the server process. 10 | # 11 | # If you need help with YAML syntax, here are some quick references for you: 12 | # https://learn-the-web.algonquindesign.ca/topics/markdown-yaml-cheat-sheet/#yaml 13 | # https://learnxinyminutes.com/docs/yaml/ 14 | # 15 | # Site settings 16 | # These are used to personalize your new site. If you look in the HTML files, 17 | # you will see them accessed via {{ site.title }}, {{ site.email }}, and so on. 18 | # You can create any custom variable you would like, and they will be accessible 19 | # in the templates via {{ site.myvariable }}. 20 | 21 | title: Your awesome title 22 | email: your-email@example.com 23 | description: >- # this means to ignore newlines until "baseurl:" 24 | Write an awesome description for your new site here. You can edit this 25 | line in _config.yml. It will appear in your document head meta (for 26 | Google search results) and in your feed.xml site description. 27 | baseurl: "" # the subpath of your site, e.g. /blog 28 | url: "" # the base hostname & protocol for your site, e.g. http://example.com 29 | twitter_username: jekyllrb 30 | github_username: jekyll 31 | 32 | # Build settings 33 | theme: minima 34 | plugins: 35 | - jekyll-feed 36 | 37 | # Exclude from processing. 38 | # The following items will not be processed, by default. 39 | # Any item listed under the `exclude:` key here will be automatically added to 40 | # the internal "default list". 41 | # 42 | # Excluded items can be processed by explicitly listing the directories or 43 | # their entries' file path in the `include:` list. 44 | # 45 | # exclude: 46 | # - .sass-cache/ 47 | # - .jekyll-cache/ 48 | # - gemfiles/ 49 | # - Gemfile 50 | # - Gemfile.lock 51 | # - node_modules/ 52 | # - vendor/bundle/ 53 | # - vendor/cache/ 54 | # - vendor/gems/ 55 | # - vendor/ruby/ 56 | -------------------------------------------------------------------------------- /docs/_includes/head_custom.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | -------------------------------------------------------------------------------- /docs/_includes/nav_footer_custom.html: -------------------------------------------------------------------------------- 1 |

We welcome your feedback about these docs!
2 | Send feedback by email or use GitHub Issues

3 | 4 | -------------------------------------------------------------------------------- /docs/_includes/toc_heading_custom.html: -------------------------------------------------------------------------------- 1 |

Topics in this section

-------------------------------------------------------------------------------- /docs/_layouts/forward.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | {% assign time = 0 %} 7 | {% assign targetname = page.target %} 8 | 9 | {% if page.time %} 10 | {% assign time = page.time %} 11 | {% endif %} 12 | 13 | {% if page.targetname %} 14 | {% assign targetname = page.targetname %} 15 | {% endif %} 16 | 17 | {% capture title %}Redirecting to {{ targetname }}{% endcapture %} 18 | {% if page.targettitle %} 19 | {% assign title = page.targettitle %} 20 | {% endif %} 21 | 22 | 23 | {{ title }} 24 | 31 | 32 | 33 |

{{ title }}

34 | 35 | {% if page.message %} 36 |

{{ page.message }}

37 | {% else %} 38 |

This document has moved!

39 | {% endif %} 40 | 41 |

Redirecting to {{ targetname }} in {{ time }} seconds.

42 | 43 | 44 | 45 | -------------------------------------------------------------------------------- /docs/_sass/color_schemes/awsstyle.scss: -------------------------------------------------------------------------------- 1 | @import "./color_schemes/dark"; 2 | 3 | //############ Body ############ 4 | 5 | $white: #E7E7E7; 6 | $grey-dk-300: #0C0C0D; 7 | $link-color: #71A621; 8 | $body-background-color: #0C0C0D; 9 | $sidebar-color:#0C0C0D; 10 | $body-font-family: "Amazon Ember", system-ui, -apple-system, blinkmacsystemfont, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif, "Segoe UI Emoji" !default; 11 | $border-color: #272727; 12 | $main-header-height: 5rem; 13 | 14 | //Regular 15 | @font-face { 16 | font-family: 'Amazon Ember'; 17 | src:url('/fonts/amazonember_w_rg.woff2') format('woff2'); 18 | font-weight:normal; 19 | font-style:normal; 20 | } 21 | @font-face { 22 | font-family: 'Vault Alarm'; 23 | src:url('/fonts/vaultalarm-regular.otf') format('opentype'); 24 | font-weight:normal; 25 | font-style:normal; 26 | } 27 | 28 | // Apply scroll padding only for larger screens 29 | @media (min-width: 50rem) { 30 | html { 31 | scroll-padding-top: $main-header-height; 32 | } 33 | } 34 | 35 | //############ _variables.scss ############ 36 | //$body-font-family: "Amazon Ember", system-ui, -apple-system, blinkmacsystemfont, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif, "Segoe UI Emoji" !default; 37 | $body-font-family: "Amazon Ember", system-ui, -apple-system, blinkmacsystemfont, sans-serif, !default; 38 | 39 | $content-width: 30rem !default; 40 | $header-height: 5rem !default; 41 | 42 | 43 | 44 | //############ Classes ############ 45 | 46 | body { 47 | //overflow-y:none !important; 48 | position:fixed; 49 | font-family: "Amazon Ember" !important; 50 | } 51 | 52 | .feedback-cta { 53 | padding-left: 1rem; 54 | font-size: 14px; 55 | } 56 | 57 | 58 | //############ Main ############ 59 | 60 | .main-header { 61 | height: $main-header-height; 62 | max-height: $main-header-height; 63 | } 64 | 65 | .main-content-wrap { 66 | padding-right: 8rem; 67 | padding-left: 4rem; 68 | } 69 | 70 | .main-content { 71 | color: #BBBBB6; 72 | font-size: 18px; 73 | font-style: normal; 74 | font-weight: normal; 75 | line-height: 1.75; /* 160% */ 76 | } 77 | 78 | .main-content h1 { 79 | 80 | color: #E7E7E7; 81 | font-family: "Vault Alarm"; 82 | font-weight: normal; 83 | font-size: 2rem !important; 84 | font-style: normal; 85 | //line-height: 2 !default; 86 | margin-top:0.1em; 87 | margin-bottom:1em; 88 | } 89 | 90 | .main-content h2 { 91 | font-family: "Amazon Ember"; 92 | font-size: 1.5rem !important; 93 | } 94 | 95 | .main-content h3 { 96 | font-family: "Amazon Ember"; 97 | font-size: 1.3rem !important; 98 | } 99 | 100 | .main-content h4 { 101 | font-family: "Amazon Ember"; 102 | font-size:1.1rem !important; 103 | font-weight: bolder; 104 | text-transform: uppercase; 105 | letter-spacing: 0; 106 | margin-top: 2em; 107 | } 108 | 109 | .main-content ul>li::before { 110 | position: static !important; 111 | } 112 | 113 | blockquote .important { 114 | background:rgba(255, 235, 130, 0.07); 115 | } 116 | 117 | blockquote .warning { 118 | background:rgba(247,126,126,0.07); 119 | } 120 | :not(pre, figure) > code { 121 | background:rgba(49, 52, 63, 0.49); 122 | } 123 | 124 | 125 | 126 | //############ Left nav ############ 127 | .site-header { 128 | height:5rem; 129 | max-height:5rem; 130 | min-height: 5rem; 131 | } 132 | .site-logo { 133 | width:65%; 134 | height:65%; 135 | } 136 | 137 | .site-title { 138 | .lh-tight { 139 | .site-logo { 140 | height:80%; 141 | } 142 | } 143 | } 144 | 145 | .site-nav { 146 | padding-top: 1.25rem; 147 | } 148 | 149 | .nav-category { 150 | color: #B0B0AB; 151 | font-size: 0.8rem !important; 152 | font-style: normal; 153 | font-weight: 700; 154 | line-height: 24px; 155 | text-transform: uppercase; 156 | margin-bottom: 0rem; 157 | margin-top: 1.5rem; 158 | border-bottom:0; 159 | } 160 | 161 | 162 | .nav-list-item { 163 | font-family: "Amazon Ember"; 164 | color: #DE7C21; 165 | font-size: 14px; 166 | font-style: normal; 167 | font-weight: 400; 168 | line-height: 36px; 169 | } 170 | 171 | 172 | .nav-list-link { 173 | color: #BBBBB6; 174 | font-family: "Amazon Ember"; 175 | font-size: 14px; 176 | font-style: normal; 177 | font-weight: 400; 178 | line-height: 36px; /* 225% */ 179 | } 180 | 181 | .nav-list .nav-list-item .nav-list-link.active { 182 | font-weight: 400; 183 | color: #DE7C21; 184 | text-decoration: none; 185 | } 186 | -------------------------------------------------------------------------------- /docs/_sass/fonts.scss: -------------------------------------------------------------------------------- 1 | //############ import font ############ 2 | //@import url('https://d1uznvntk80v7s.cloudfront.net/fonts/AmazonEmber_W_Rg.woff2'); 3 | 4 | 5 | //Regular 6 | @font-face { 7 | font-family: 'Amazon Ember'; 8 | src:url('https://d1uznvntk80v7s.cloudfront.net/fonts/AmazonEmber_W_Rg.woff2') format('woff2'); 9 | font-weight:normal; 10 | font-style:normal; 11 | } 12 | 13 | -------------------------------------------------------------------------------- /docs/_sass/fonts/AmazonEmber_W_Rg.woff2: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/_sass/fonts/AmazonEmber_W_Rg.woff2 -------------------------------------------------------------------------------- /docs/authorization.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: forward 3 | target: auth/authorization.html 4 | --- 5 | 6 | 7 | -------------------------------------------------------------------------------- /docs/bp-implementing-roles-attributes.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: forward 3 | target: bestpractices/bp-implementing-roles-attributes.html 4 | --- 5 | 6 | 7 | -------------------------------------------------------------------------------- /docs/bp-implementing-roles-groups.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: forward 3 | target: bestpractices/bp-implementing-roles-groups.html 4 | --- 5 | 6 | 7 | -------------------------------------------------------------------------------- /docs/bp-implementing-roles-templates.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: forward 3 | target: bestpractices/bp-implementing-roles-templates.html 4 | --- 5 | 6 | 7 | -------------------------------------------------------------------------------- /docs/bp-implementing-roles.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: forward 3 | target: bestpractices/bp-implementing-roles.html 4 | --- 5 | 6 | 7 | -------------------------------------------------------------------------------- /docs/bp-meta-permissions.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: forward 3 | target: bestpractices/bp-meta-permissions.html 4 | --- 5 | 6 | 7 | -------------------------------------------------------------------------------- /docs/bp-mutable-identifiers.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: forward 3 | target: bestpractices/bp-mutable-identifiers.html 4 | --- 5 | 6 | 7 | -------------------------------------------------------------------------------- /docs/bp-naming-conventions.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: forward 3 | target: bestpractices/bp-naming-conventions.html 4 | --- 5 | 6 | 7 | -------------------------------------------------------------------------------- /docs/bp-normalize-data-input.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: forward 3 | target: bestpractices/bp-normalize-data-input.html 4 | --- 5 | 6 | 7 | -------------------------------------------------------------------------------- /docs/bp-populate-policy-scope.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: forward 3 | target: bestpractices/bp-populate-policy-scope.html 4 | --- 5 | 6 | 7 | -------------------------------------------------------------------------------- /docs/bp-using-the-context.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: forward 3 | target: bestpractices/bp-using-the-context.html 4 | --- 5 | 6 | 7 | -------------------------------------------------------------------------------- /docs/collections/_auth/images/AVP-BASICS.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_auth/images/AVP-BASICS.jpg -------------------------------------------------------------------------------- /docs/collections/_auth/images/Cedar 1 - black.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_auth/images/Cedar 1 - black.png -------------------------------------------------------------------------------- /docs/collections/_auth/images/Cedar 1 - white.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_auth/images/Cedar 1 - white.png -------------------------------------------------------------------------------- /docs/collections/_auth/images/Cedar 2 - black.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_auth/images/Cedar 2 - black.png -------------------------------------------------------------------------------- /docs/collections/_auth/images/Cedar 2 - green.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_auth/images/Cedar 2 - green.png -------------------------------------------------------------------------------- /docs/collections/_auth/images/Cedar 2 - white.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_auth/images/Cedar 2 - white.png -------------------------------------------------------------------------------- /docs/collections/_auth/images/Cedar1-green.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_auth/images/Cedar1-green.png -------------------------------------------------------------------------------- /docs/collections/_auth/images/PhotoFlash.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_auth/images/PhotoFlash.png -------------------------------------------------------------------------------- /docs/collections/_auth/images/entities.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_auth/images/entities.png -------------------------------------------------------------------------------- /docs/collections/_auth/images/hierarchy.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_auth/images/hierarchy.png -------------------------------------------------------------------------------- /docs/collections/_auth/images/quotas-transitive-parents.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_auth/images/quotas-transitive-parents.png -------------------------------------------------------------------------------- /docs/collections/_auth/images/resource-lives-in-container.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_auth/images/resource-lives-in-container.png -------------------------------------------------------------------------------- /docs/collections/_auth/images/security-of-cedar.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_auth/images/security-of-cedar.png -------------------------------------------------------------------------------- /docs/collections/_auth/images/separate-principals-from-resources-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_auth/images/separate-principals-from-resources-2.png -------------------------------------------------------------------------------- /docs/collections/_auth/images/separate-principals-from-resources-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_auth/images/separate-principals-from-resources-3.png -------------------------------------------------------------------------------- /docs/collections/_auth/images/separate-principals-from-resources.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_auth/images/separate-principals-from-resources.png -------------------------------------------------------------------------------- /docs/collections/_auth/images/source/entities.drawio: -------------------------------------------------------------------------------- 1 | 7VrbctowEP0aPybjO+kjlyTNQ2fSYTqlfckIW7GVyJYri1u/vitbxhcMgYQESHlCeyStdlfnCNmgWf1ofstREn5jPqaaqftzzRpopml0dAc+JLLIkY6tgIATXw0qgSH5ixWoK3RCfJzWBgrGqCBJHfRYHGNP1DDEOZvVhz0yWl81QQFeAYYeoqvoT+KLMEevHL3Ev2IShMXKhq56IlQMVkAaIp/NKpB1rVl9zpjIW9G8j6ksXlGXfN7Nmt5lYBzHYpsJXnLXZc73CN+F9kOfGaOn0e8L5WWK6EQlrJkuihLN6sXjVH6IRQI93R8p5tBFYaneWLYC2WoOxnKxriYjcf9MZGa9JxTj0mp1kSE+mTahNEHxupWQ57GJTFyu1i0NaW9eGirUcFzAtRCyLROLggccFvCxLKUO3bOQCDxMkCd7Z8B8wEIRUbAMGRwlQQxtih9LZ1PMBZ6v3TxjSQnQEmYRFnwBQ5RszCvFollJQsNWWFghoKswpHgfLF2V1ICGYscOTDHbmFLZpkqxiopnVbpI8zLJfYoZjxCtbUnr5tY5V+t6YRclr94YyTvl1CKNMRvX5h0i0Yzz+8xzG2E2Ez8BAVruoQVoHUyAn0ZwQAtv+2+Ek5bY+lSPWGS2fWiR2WeRvVVkTyyM/w+Nrc30iCXmmIeWmPPxEruFoiefSmPwZPPwiCJCF6cvNTaL4QTMpmRn4bZPcceoMjXBLN4CHM3t0T2rbk+q4wTHfnqW3RHKzm7I7vD3yc5ZdvuRncdmjD9jfhbeMQqv+X13+Fum0fZmu1E07Ad4qEzGRcgCFiN6XaLVosGh35W/J4A5psx7lhAdZ7YsHfFg60EQAnFRjItZjPOZN4QWflLB2TPuM8p4FoXl2E7PtaGnvod4TsSoWBvavyR+6ShrMK8MGywKI4bSjapGZZY0y2mZVczLKyPLsXn/oXpswj28oe6qylCGAIuXngJW+VTlS8EpjikSZFqPrY0wyt09IxD1kptGnZqu3qBcnpKaVP39pOnnJUd5ziuOMvouU3wDo9vewJ8Z/e6MtrZktPtxjHYa15zXUrqpjRVH703pttdtJ0Xpgp4X+qXeMXbjaGbdY06gjPIasCNxj4iQlt143P3ySkJanQYhO9sREjYTLSrDEjkg3RBwpz3gXeMq9ZBHsF91tL0pOyl1vOLA3+PBbZ/ggdy8Rzv7OpDBLP9qkg8v/7BjXf8D -------------------------------------------------------------------------------- /docs/collections/_auth/images/structure-of-policy.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_auth/images/structure-of-policy.png -------------------------------------------------------------------------------- /docs/collections/_auth/images/transitive-attributes-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_auth/images/transitive-attributes-2.png -------------------------------------------------------------------------------- /docs/collections/_auth/images/transitive-attributes-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_auth/images/transitive-attributes-3.png -------------------------------------------------------------------------------- /docs/collections/_auth/images/transitive-attributes.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_auth/images/transitive-attributes.png -------------------------------------------------------------------------------- /docs/collections/_bestpractices/bp-compound-auth.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Compound authorization 4 | nav_order: 2 5 | --- 6 | 7 | # Best practice: Compound authorization is normal 8 | 9 | {: .no_toc } 10 | 11 | Compound authorization occurs when a single user activity, such as clicking a button in your application's interface, requires multiple individual authorization queries to determine whether that activity is permitted. For example, moving a file to a new directory in a file system might require three different permissions: the ability to delete a file from the source directory, the ability to add a file to the destination directory, and possibly the ability to touch the file itself (depending on the application). 12 | 13 | If you're new to designing an authorization model, you might think that every authorization decision must be resolvable in a single authorization query. But this can lead to overly complex models and convoluted policy statements. In practice, using compound authorizations can be useful in helping you to produce a simpler authorization model. One measure of a well-designed authorization model is that when you have sufficiently decomposed individual actions, your compound operations, such as moving a file, can be represented by an intuitive aggregation of primitives. 14 | 15 | Another situation where compound authorization occurs is when multiple parties are involved in the process of granting a permission. Consider an organizational directory where users can be members of groups. A simple approach is to give the group owner permission to add anyone. However, what if you want your users to first consent to being added? This introduces a handshake agreement in which both the user and the group must consent to the membership. To accomplish this, you can introduce another permission that is bound to the user and specifies whether the user can be added to any group, or to a particular group. When a caller subsequently attempts to add members to a group, the application must enforce both sides of the permissions: that the caller has permission to add members to the specified group, and that the individual user being added has the permissions to be added. When N-way handshakes exist, it is common to observe N compound authorization queries to enforce each portion of the agreement. 16 | 17 | If you find yourself with a design challenge where multiple resources are involved and it is unclear how to model the permissions, it can be a sign that you have a compound authorization scenario. In this case, a solution might be found by decomposing the operation into multiple, individual authorization checks. 18 | -------------------------------------------------------------------------------- /docs/collections/_bestpractices/bp-fine-grained-permissions.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Permissions 4 | nav_order: 3 5 | --- 6 | 7 | # Best practice: Prefer fine-grained permissions in the model and aggregate permissions in the user interface 8 | 9 | {: .no_toc } 10 | 11 | One strategy that designers often regret later is designing an authorization model with very broad actions, such as Read and Write, and realizing later that finer-grained actions are necessary. The need for finer granularity can be driven by customer feedback for more granular access controls, or by compliance and security auditors who encourage least-privilege permissions. 12 | 13 | If fine-grained permissions are not defined upfront, it can require a complicated conversion to modify the application code and policy statements to user finer grained permissions. For example, application code that previously authorized against a course-grained action will need to be modified to use the fine-grained actions. In addition, policies will need to be updated to reflect the migration: 14 | 15 | ```Cedar 16 | permit ( 17 | principal == User::"6688f676-1aa9-456a-acf4-228340b54e9d", 18 | // action == Action::"read", -- coarse-grained permission -- commented out 19 | action in [ // -- finer grained permissions 20 | Action::"listFolderContents", 21 | Action::"viewFile" 22 | ], 23 | resource in Account::"c863f89b-461f-4fc2-b638-e5fa5f79a48b" 24 | ); 25 | ``` 26 | 27 | To avoid this costly migration, it's better to define fine-grained permissions upfront. However, this can result in a tradeoff if your end-users are subsequently forced to understand a larger number of fine-grained permissions, especially if most customers would be satisfied with course-grained controls such as `Read` and `Write`. To attain the best of both worlds, you can group fine-grained permissions into predefined collections such as `Read` and `Write` using mechanisms like policy templates or action groups. By using this approach, customers see only the course-grained permissions. But behind the scenes, you've future-proofed your application by modeling the course-grained permissions as a collection of fine-grained actions. When either customers or auditors ask for it, the fine-grained permissions can be exposed. 28 | -------------------------------------------------------------------------------- /docs/collections/_bestpractices/bp-implementing-roles-attributes.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | parent: Using role-based access control 4 | title: Attribute-based conditions 5 | nav_order: 2 6 | has_children: false 7 | --- 8 | 9 | # When to use attribute-based conditions 10 | 11 | [The approach described in the previous section](bp-implementing-roles-groups.html) requires that you add a new user group in your identity provider (IdP) and create a new policy for each group of resources. In the previous examples, the resource groups reflect countries: `Approver-France`, `Approver-Germany`, `Approver-UK`, and so on. There is a finite number of countries, and they don’t change very often. The company might expand into five new countries per year, and so creating new user groups in the IdP and new policies to support this expansion might not represent a significant overhead. 12 | 13 | However, consider instead a scenario where the resource groups represent projects instead of countries. Each time a project is kicked off one or more approvers must be assigned to review and approve timesheets for that project. A large global company might be starting and stopping hundreds of projects a year. With the previous approach, for every project that is kicked off a new user group representing the approver role for that project’s timesheets needs to be created in the IdP: `Approver-project03344`, `Approver-project03345`, `Approver-project03346`, and so on. This could have an impact on management of your directory, adding thousands of roles. 14 | 15 | In such a scenario, you should consider whether you can use attribute-based conditions to determine which resource the role is permitted to act on. If the principal has a attribute that indicates a list of projects that the principal is assigned to and the timesheet also has a project attribute, then you can create a single policy for approvers, with an attribute condition that compares these two values, as shown in the following example. 16 | 17 | ```cedar 18 | // Role to approve timesheets for the principal's assigned projects 19 | permit ( 20 | principal in Role::"Approver", 21 | action in Action::"ApproverActions", 22 | resource in TimesheetGrp::"all-timesheets" 23 | ) when { 24 | principal.assignedProjects.contains(resource.project) 25 | }; 26 | ``` 27 | 28 | ## Assigning a role to a user 29 | 30 | An administrator can assign a user to the Approver role by adding them as a member of the group called `Role::"Approver"`. In addition, the administrator must set the value of the `assignedProjects` attribute to specify **which** projects a particular principal can approve. 31 | 32 | This provides an elegant solution _if_ the attributes exist or can be determined in real time by the application. However, if you must extend your application to record and maintain these attributes solely for the purpose of permissions management, then you might be better off recording this information in the policy store in the form of policies. 33 | 34 | ## Making an Authorization Request 35 | 36 | The application must call [`IsAuthorized`](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorized.html) and pass through [`entities`](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorized.html#verifiedpermissions-IsAuthorized-request-entities) data that describes the principal’s group memberships and the resource’s group memberships. The application must also include the value of the relevant attributes, such as the `assignedProjects` attribute on the principal and the `project` attribute on the resource. 37 | 38 | ## Expanding to a new country 39 | 40 | Expanding to a new country doesn’t require any changes to your policies. 41 | -------------------------------------------------------------------------------- /docs/collections/_bestpractices/bp-implementing-roles-groups.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | parent: Using role-based access control 4 | title: Groups and resource-specific roles 5 | nav_order: 1 6 | has_children: false 7 | --- 8 | 9 | # RBAC with groups and resource-specific roles 10 | 11 | We can extend the ‘role management using groups’ approach, and create a separate approver group for each set of resources: `Approver-France`, `Approver-Germany`, and `Approver-UK`. 12 | 13 | Each role is represented by a policy in the policy store, as shown in the following example. 14 | 15 | ```cedar 16 | // Role to approve French timesheets 17 | permit ( 18 | principal in Role::"Approver-France", 19 | action in Action::"ApproverActions", 20 | resource in TimesheetGrp::"French-timesheets" 21 | ); 22 | ``` 23 | 24 | ```cedar 25 | // Role to approve German timesheets 26 | permit ( 27 | principal in Role::"Approver-Germany", 28 | action in Action::"ApproverActions", 29 | resource in TimesheetGrp::"German-timesheets" 30 | ); 31 | ``` 32 | 33 | ```cedar 34 | // Role to approve UK timesheets 35 | permit ( 36 | principal in Role::"Approver-UK", 37 | action in Action::"ApproverActions", 38 | resource in TimesheetGrp::"UK-timesheets" 39 | ); 40 | ``` 41 | 42 | ## Assigning a User to a Role 43 | 44 | An administrator can assign a user to the role by adding them as a member of the associated group. For example, Bob is a member of groups `Approver-France` and `Approver-Germany`. Alice is a member of groups `Approver-France` and `Approver-UK`. 45 | 46 | The policy store isn't maintaining a record of which roles a user is assigned to, such as which groups a principal is a member of. You must keep track of this using a system separate from Cedar, such as your IdP. 47 | 48 | ## Making an Authorization Request 49 | 50 | Consider an application using Cedar policies in the Amazon Verified Permssions service. The application needs to call the [`IsAuthorized`](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorized.html) operation, passing through [`entities`](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorized.html#verifiedpermissions-IsAuthorized-request-entities) data that describes the principal’s group memberships and the resource’s group memberships. 51 | 52 | For example, an authorization request to determine whether Alice can approve JeanPaul’s timesheet must include the following: 53 | 54 | * The list of groups that the principal Alice is a member of. 55 | * The list of groups that resource JeanPaul’s timesheet is a member of. 56 | 57 | If you are building your own authorization engine, using the Cedar SDK, then you must also pass all relevant policies, as part of the request. If you are using a hosted service, such as Amazon Verified Permissions, then the service can select the relevant policies for evaluation from its policy store. 58 | 59 | ## Expanding to a new country 60 | 61 | Adding a new country requires you to create of a new group in the IdP to represent the country specific role, and to add a new policy for that group. 62 | 63 | For example, to expand into Japan, you might create a new user group called `Approver-Japan` and a new policy that references that group. This policy permits members of that group to approve only Japanese timesheets. 64 | 65 | ```cedar 66 | // Role policy to approve Japanese timesheets 67 | permit ( 68 | principal in Role::"Approver-Japan", 69 | action in Action::"ApproverActions", 70 | resource in TimesheetGrp::"Japanese-timesheets" 71 | ); 72 | ``` 73 | For more information, see [Manage roles and entitlements with PBAC using Amazon Verified Permissions](https://aws.amazon.com/blogs/devops/manage-roles-and-entitlements-with-pbac-using-amazon-verified-permissions/) on the _AWS DevOps Blog_. 74 | 75 | To see a sample application, see [avp-petstore-sample-v2](https://github.com/aws-samples/avp-petstore-sample-v2) on _GitHub_. 76 | -------------------------------------------------------------------------------- /docs/collections/_bestpractices/bp-implementing-roles-templates.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | parent: Using role-based access control 4 | title: Roles with policy templates 5 | nav_order: 3 6 | has_children: false 7 | --- 8 | 9 | # Role management using policy templates 10 | 11 | The recommended approach to implementing role-based access control in Cedar is to use principal groups to represent the roles. However, this requires a system of record, such as an identity provider (IdP), to keep track of which users are assigned to which roles. If this isn't an option, then you can manage role assignment within your policy store by using policy templates. 12 | 13 | Using this approach, you create a template for each of the roles. So, continuing with the timesheet example from the previous sections, you create a Worker template and an Approver template. 14 | 15 | ```cedar 16 | // Approver-Role-Assignment policy template 17 | permit ( 18 | principal == ?principal, 19 | action in Action::"ApproverActions", 20 | resource in ?resource 21 | ); 22 | ``` 23 | 24 | ## Assigning a role to a user 25 | 26 | In this approach, it is the policy store that keeps track of which roles a user is assigned to. To assign a user to a role, we must instantiate a template-linked policy that links the specific user and resource group. For example, to assign Alice to the approver role for France and the UK, we create two template-linked policies from the role template. 27 | 28 | ``` 29 | createPolicy ( 30 | template = "Approver-Role-assignment", 31 | principal = User::"Alice", 32 | resource = TimesheetGrp::"UK" 33 | ) 34 | ``` 35 | 36 | ``` 37 | createPolicy ( 38 | template = "Approver-Role-assignment", 39 | principal = User::"Alice", 40 | resource = TimesheetGrp::"France" 41 | ) 42 | ``` 43 | 44 | You can see that each template-linked policy grants permissions to a specified user to perform the actions in the template on the specified resources in the resource group. 45 | 46 | ## Making an authorization request 47 | 48 | The entity data within the authorization request must include the group membership of the resource. However, this approach doesn’t need to include group memberships of the principal, because we created a separate template-linked policy for each assigned principal. 49 | 50 | ## Expanding to a new country 51 | 52 | To create an approver role for a new country, it's not necessary to add a new user group in the IdP, or create a new policy or template. The only configuration activity required is to create of a new resource group to contain the resources for that country. For example, when the company expands into Japan it must add a new resource group called `TimesheetGrp::"Japanese-timesheets"`. 53 | 54 | ## Considerations when using templates 55 | 56 | If you use the template approach, you tightly couple the policy store to the life-cycle management of your users. When you onboard a new user and assign them to a role, you must create template-linked policies for them. When that user changes roles, you must find those policies, archive them, and then create new template-linked policies. When the user leaves the organization, you must archive the policies for that user. If you delete the policies instead of archiving them, then you lose the historical record of who was permitted to do what, which might be required for forensics purposes. 57 | 58 | These challenges reinforce each other if the role is a complex set of permissions requiring multiple policies. In the simple example above, the permissions for the role can be expressed as a single policy statement. Therefore, assigning a principal requires the creation of a single template-linked policy. However, more complex roles might require several policies to express the permissions. In that case, the assignment and unassignment processes can become more burdensome, as you must create or delete multiple template-linked policies. 59 | -------------------------------------------------------------------------------- /docs/collections/_bestpractices/bp-implementing-roles.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Using role-based access control 4 | nav_order: 12 5 | has_children: true 6 | --- 7 | 8 | # Best practice: Use role-based access control as part of your authorization strategy 9 | 10 | {:toc} 11 | 12 | This topic helps you to understand how to implement role-based access control (RBAC) by using Cedar. It describes the recommended approach of using principal groups to represent roles. This topic assumes that you are using Cedar with some sort of hosted policy store. This can be a policy store that you built, or that is part of a commercial product, such as Amazon Verified Permissions. 13 | 14 | ## What is a role? 15 | 16 | We can define a *role* as a set of tasks that you assign to a person or thing (the principal) for a specific purpose. To perform those tasks, the principal needs permissions to perform the appropriate operations on the relevant resources. You express those permissions as Cedar policies. 17 | 18 | * Roles are defined independently of the principals to which they are assigned. 19 | * A principal can be assigned to many roles, or none at all. 20 | * Assigning a role grants the assigned principal permission to do specific operations on specific resources. 21 | 22 | ## Modeling roles in Cedar by using groups 23 | 24 | The recommended approach to modeling roles in Cedar is to use groups of principals to represent roles. You express the permissions for that role as one or more policies for that principal group. You then assign principals to the role by making them members of the group. You manage role assignment independently from the policy store, typically by using an identity provider (IdP). 25 | 26 | For example, consider a timesheet management system that has two roles: (1) workers who submit timesheets and (2) approvers who approve the timesheets. A single individual can be assigned both roles. The following topics evaluate this scenario using the following strategies. 27 | 28 | Using the recommended approach you would create groups for each of these roles. So we’d have a `Worker` group, and an `Approver` group. Within the policy store we would create policies for each group. 29 | 30 | The policy for the Approver role would look like this 31 | 32 | ```cedar 33 | // Permits any member of the group Role::"Approver" to review and approve timesheets 34 | permit ( 35 | principal in Role::"Approver", 36 | action in [Action::"TimeSheetReview", Action::"TimeSheetApprove"], 37 | resource in TimesheetGrp::"all-timesheets" 38 | ); 39 | ``` 40 | 41 | Note that we’ve also created a resource group called `TimesheetGrp::"all-timesheets"`. As the name suggests, all timesheets are members of this resource group. 42 | 43 | We can simplify this policy a little bit by creating an Action group. In this case we’d create an action group called `ApproverActions` , with the members `Action::"TimeSheetReview"` and `Action::"TimeSheetApprove"`. 44 | 45 | We can now rewrite the policy as the following: 46 | 47 | ```cedar 48 | // Permits any member of the group Role::"Approver" to review and approve timesheets 49 | permit ( 50 | principal in Role::"Approver", 51 | action in Action::"ApproverActions", 52 | resource in TimesheetGrp::"all-timesheets" 53 | ); 54 | ``` 55 | 56 | Action groups can be defined in your schema, so your application doesn’t need to pass action group memberships as part of the entity data of an authorization request. A benefit of Action groups is that you can now add another action to the Approver role by simply adding the new action to the definition of `Action::"ApproverActions"` in the schema. You do ***not*** have to update any of your policies. 57 | If we want to assign Joe to the role of Approver, we add him as a member of the group called `Role::"Approver"`. That information needs to be tracked outside of the policy store, potentially in the IdP, or some other system of record. Assigning and unassigning principals to a role doesn’t require us to modify any policies. 58 | 59 | When making an authorization request, we need to provide information about which groups the principal is in. For example, when asking whether `User::"Joe"` is permitted to take the action `TimeSheetReview`, we need to provide the authorization engine with the information that Joe is a member of the group `Role::"Approver"`. 60 | 61 | ## Managing resource-specific roles 62 | 63 | So far, we’ve kept things very simple. A principal assigned to the Approver role can approve all timesheets. Things get more complicated when a role must be assigned for a specific subset of resources. For example, the timesheet-approver role could be country-specific. Bob might be authorized to approve timesheets in Germany and France, while Alice can approve timesheets in France and the UK. 64 | 65 | The following sections explore two different ways to do this. The first approach creates resource-specific roles. The second approach adds an attribute condition to the group policies. We assume that the timesheets are organized into per-country resource groups. 66 | -------------------------------------------------------------------------------- /docs/collections/_bestpractices/bp-meta-permissions.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Meta-permissions 4 | nav_order: 10 5 | --- 6 | 7 | # Design: Implement meta-permissions as policies 8 | {: .no_toc } 9 | 10 | Authorization systems must contend not only with permissions to resources, but also who has the permission to modify permissions. These meta-permissions, or admin permissions, are themselves a part of the authorization model and should be included in the design exercise. 11 | 12 | One simple approach to meta-permissions is to introduce a new action, such as `editPermissions`, that can be referenced in policies just like any other action. 13 | 14 | ```cedar 15 | permit ( 16 | principal == User::"&ExampleToken1;", 17 | action == Action::"editPermissions", 18 | resource in Account::"&ExampleToken2;" 19 | ); 20 | ``` 21 | 22 | The application would then confirm whether a principal has this capability whenever they attempt to modify permissions on a resource. 23 | 24 | Richer implementations may choose more granular meta-permissions, such as `editReadPermissions` or `editWritePermissions`. Alternatively, an ABAC-style approach can be used in which resources are decorated with an attribute such as `owner`, and a global ABAC rule that allows owners to manage access: 25 | 26 | ```cedar 27 | permit ( 28 | principal, 29 | action == Action::"editPermissions", 30 | resource 31 | ) 32 | when { 33 | principal == resource.owner 34 | }; 35 | ``` 36 | 37 | The ABAC-style approach also makes it very important to protect the value of `owner` and who can change it. The solution that any application chooses ties back to the user experience. Application designers must decide which principals can have these meta-permissions and how they manage them in the application UX. With that understanding in place, the administrative experience can be mapped into a corresponding authorization model. 38 | -------------------------------------------------------------------------------- /docs/collections/_bestpractices/bp-mutable-identifiers.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Avoid mutable identifiers 4 | nav_order: 11 5 | --- 6 | 7 | # Security requirement: Avoid mutable identifiers in policies 8 | {: .no_toc } 9 | 10 | Mutable identifiers can't be used in policy statements. An example of a mutable identifier is a user name or group name in a workforce directory, where the value of the name can change. Usage of such a name in a policy may appear as follows: 11 | 12 | ```cedar 13 | permit ( 14 | principal in Group::"TeamExample", 15 | action in ..., 16 | resource in ... 17 | ); 18 | ``` 19 | 20 | If the group name was changed, it would no longer match this policy. If the group was deleted and the name was reused for a different group, the new group members would receive the permissions of any policies that hadn’t been removed when the original group was deleted. 21 | 22 | For these reasons, policies must refer to only unique, normalized, immutable, and non-recyclable identifiers. Use universally unique identifiers (UUIDs) or similar formats that meet the same criteria, such as sequence numbers or uniform resource names (URNs). 23 | 24 | ```cedar 25 | permit ( 26 | principal in Group::"fcaf664d4f89fec0cda8", // "TeamExample" 27 | action in ..., 28 | resource in ... 29 | ); 30 | ``` 31 | -------------------------------------------------------------------------------- /docs/collections/_bestpractices/bp-naming-conventions.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Naming conventions 4 | nav_order: 1 5 | --- 6 | 7 | # Best practice: Define and use naming conventions 8 | 9 | {: .no_toc } 10 | 11 | To help ensure consistency in your Cedar policies, we recommend that you define and use a naming convention for the elements in your schema. For example: 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 |
Identifier typeNaming conventionExamples
 Entity type  PascalCase (camelCase with first letter capitalized)  User 
 Entity instance Id  Opaque Id or camelCase  fcaf664d4f89fec0cda8 
 viewFile
 Attribute names  camelCase  resource.countryOfOrigin 
 Context keys  camelCase  context.uploadFileSize 
 context.http.headers.userAgent 
40 | -------------------------------------------------------------------------------- /docs/collections/_bestpractices/bp-normalize-data-input.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Normalize data input 4 | nav_order: 8 5 | --- 6 | 7 | # Security requirement: Normalize input data prior to invoking the authorization APIs 8 | {: .no_toc } 9 | 10 | The Cedar policy language omits some well-known operators, including those used to format data and to manipulate and transform strings and lists. This omission is intentional. One reason why is that these operators disrupt the ability to apply automated reasoning techniques to Cedar policy statements. Another reason that Cedar does not provide operators is that Cedar is designed to support situations where policy authors can be outside of the development team, or even be external customers. To provide a safe, intuitive policy authoring experience for these audiences, each individual policy author should not be required to discover and apply appropriate formatting rules. 11 | 12 | As a result, application owners should format data prior to passing it into the authorization APIs. For example, instead of passing the following data in the context record: 13 | 14 | ```json 15 | { 16 | "url": "https://example.com/path/to/page?name=alice&color=red" 17 | } 18 | ``` 19 | 20 | The information should be pre-formatted into something more accessible by policy authors: 21 | 22 | ```json 23 | { 24 | "url": { 25 | "transport": "https", 26 | "host": "example.com", 27 | "path": "/path/to/page" 28 | "queryParams": { 29 | "name": "alice", 30 | "color": "red" 31 | } 32 | } 33 | ``` 34 | 35 | Special attention should be paid to the normalization of strings. For example, consider the following URL which resolves to the same resource as the example above. 36 | 37 | ```json 38 | { 39 | "url": "https://EXAMPLE.COM////path/to/page?name=alice&color=red" 40 | } 41 | ``` 42 | 43 | Note the capitalization of `EXAMPLE.COM` and multiple `/` characters at the beginning of the path. All must be normalized into a consistent representation prior to authorization. Otherwise, as shown in the following example policy, the rules may not behave as the author expects. 44 | 45 | ```cedar 46 | permit (principal, action, resource) 47 | when { 48 | context.url.host == "example.com" && // Won't match "EXAMPLE.COM" 49 | context.url.path == "/path/to/page" // Won't match "///path/to/page" 50 | }; 51 | ``` 52 | 53 | Normalization requirements also apply to entity identifiers. For example, consider a service that accepts UUIDs with or without embedded dashes, or with different capitalization: 54 | 55 | ``` 56 | // All of the following will return the same object. 57 | service.getObject(objectId: "a9edd19b-46f3-486b-887d-4c378aced880"); 58 | service.getObject(objectId: "A9EDD19B-46F3-486B-887D-4C378ACED880"): 59 | service.getObject(objectId: "a9edd19b46f3486b887d4c378aced880"); 60 | ``` 61 | 62 | If a service accepts all formats of the identifier, which format can be reliably used in Cedar policies? The service must choose one normalized format and use it consistently during authorization queries. The impacts of doing otherwise can lead to a risk, as illustrated in the following example: 63 | 64 | ```cedar 65 | // This policy won't match if the Object ID is provided in a different format. 66 | // This allows the caller to bypass the forbid rule and retrieve the object. 67 | forbid ( 68 | principal, 69 | action == Action::"getObject", 70 | resource == Object::"a9edd19b-46f3-486b-887d-4c378aced880" 71 | ); 72 | ``` 73 | 74 | As these examples demonstrate, pre-normalization of data is important for policy analysis, policy authoring, and the overall security of the application. Careful consideration should be given to ensure that all string inputs are normalized prior to invoking the authorization APIs. 75 | -------------------------------------------------------------------------------- /docs/collections/_bestpractices/bp-other-considerations.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Other considerations 4 | nav_order: 13 5 | --- 6 | 7 | # Best practice: Consider other reasons to query authorization 8 | 9 | {: .no_toc } 10 | 11 | We usually associate authorization checks with user requests. The check is a way to determine whether the user has permission to perform that request. However, you can also use authorization data to influence the design of the application's interface. For example, you might want to display a home screen that shows a list of only those resources that the end-user can access. When viewing the details of a resource, you might want the interface to show only those operations that the user can perform on that resource. 12 | 13 | These situations can introduce tradeoffs into the authorization model. For example, heavy reliance on attributed-based access control (ABAC) policies can make it more difficult to quickly answer the question "who has access to what?" This is because answering that question requires examining each rule against every principal and resource to determine if there is a match. As a result, a product that needs to optimize for listing only those resources accessible by the user might choose to use a role-based access control (RBAC) model. By using RBAC, it can be easier to iterate over all the policies attached to a user to determine resource access. 14 | -------------------------------------------------------------------------------- /docs/collections/_bestpractices/bp-overview.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Best Practices overview 4 | nav_order: 0 5 | --- 6 | 7 | # Cedar best practices 8 | 9 | The best practices included here outline the most up-to-date recommendations to get the most out of using Cedar as your authorization engine. 10 | 11 | **Best practices** 12 | 13 | * [Define and use naming conventions](../bestpractices/bp-naming-conventions.html) 14 | * [Map actions to the business domain](#bp-map-actions) 15 | * [Model all permissions in Cedar](#bp-model-all-perms) 16 | * [Take advantage of user groups](#bp-user-groups) 17 | * [Compound authorization is normal](../bestpractices/bp-compound-auth.html) 18 | * [Prefer fine-grained permissions in the model and aggregate permissions in the user interface ](../bestpractices/bp-fine-grained-permissions.html) 19 | * [Use attributes or templates to represent relationships ](../bestpractices/bp-relationship-representation.html) 20 | * [Every resource lives in a container ](../bestpractices/bp-resources-containers.html) 21 | * [Separate the principals from the resource containers ](../bestpractices/bp-separate-principals.html) 22 | * [When possible, populate the policy scope ](../bestpractices/bp-populate-policy-scope.html) 23 | * [Normalize input data prior to invoking the authorization APIs](../bestpractices/bp-normalize-data-input.html) 24 | * [Don’t use the context field to hold information about the principal, action, and resource ](../bestpractices/bp-using-the-context.html) 25 | * [Implement meta-permissions as policies](../bestpractices/bp-meta-permissions.html) 26 | * [Avoid mutable identifiers in policies ](../bestpractices/bp-mutable-identifiers.html) 27 | * [Use role-based access control as part of your authorization strategy](../bestpractices/bp-implementing-roles.html) 28 | * [Consider other reasons to query authorization ](../bestpractices/bp-other-considerations.html) 29 | * [Define and use naming conventions](../bestpractices/bp-naming-conventions.html) 30 | 31 | ## Map actions to the business domain {#bp-map-actions} 32 | 33 | 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. 34 | 35 | ## Model all permissions in Cedar {#bp-model-all-perms} 36 | 37 | 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. 38 | 39 | ## Take advantage of user groups {#bp-user-groups} 40 | 41 | 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](../overview/terminology.html#term-group) that map to the different kinds of users you have and control their permissions at the group level. 42 | -------------------------------------------------------------------------------- /docs/collections/_bestpractices/bp-populate-policy-scope.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Populate the policy scope 4 | nav_order: 7 5 | --- 6 | 7 | # Best practice: When possible, populate the policy scope 8 | {: .no_toc } 9 | The [policy scope](../overview/terminology.html#policy) is the portion of a Cedar policy statement after the `permit` or `forbid` keywords and between the opening parenthesis. 10 | 11 | ![\[Illustrates the structure of a Cedar policy, including the scope.\]](images/structure-of-policy.png) 12 | 13 | We recommend that you populate the values for `principal` and `resource` whenever possible. This lets you index your policies in storage for more efficient retrieval, which can improve performance. If you need to grant the same permissions to many different principals or resources, we recommend that you use a [policy template](../policies/templates.html) and attach it to each principal and resource pair. 14 | 15 | Avoid creating one large policy that contains lists of principals and resources in a `when` clause. Doing so will likely cause you to run into scalability limits or operational challenges. For example, in order to add or remove a single user from a large list within a policy, it is necessary to read the whole policy, edit the list, write the new policy in full, and handle concurrency errors if one administrator overwrites another’s changes. In contrast, by using many fine-grained permissions, adding or removing a user is as simple as adding or removing the single policy that applies to them. 16 | -------------------------------------------------------------------------------- /docs/collections/_bestpractices/bp-relationship-representation.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Representing relationships 4 | nav_order: 4 5 | --- 6 | 7 | # Best practice: Use attributes or templates to represent relationships 8 | {: .no_toc } 9 | 10 | There are two main ways to express relationships between resources. When to use one or the other depends on whether or not the relation is already stored in your application database and used for other reasons such as compliance. If it is, take the [attribute-based approach](#attribute-based). If not, then take the [template-based approach](#template-based). 11 | 12 |
13 | 14 | Topics on this page 15 | 16 | {: .text-delta } 17 | - TOC 18 | {:toc} 19 |
20 | 21 | ## Attribute-based relationships {#attribute-based} 22 | 23 | Attributes can be used as an *input* to the authorization decision to represent a relationship between a principal and one or more resources. 24 | 25 | This pattern is appropriate where the relationship is tracked and managed for purposes beyond just permissions management. For example, recording the primary account holder is required for financial compliance with *Know Your Customer* rules. Permissions are derived from these relationships. The relationship data is managed outside of the authorization system, and fetched as an input when making an authorization decision. 26 | 27 | The following example shows how a relationship between a user `Alice` and a number of accounts on which she is the primary account holder could be represented: 28 | 29 | ```Cedar 30 | // Using a user attribute to represent the primary account holder relationship 31 | { 32 | "id": "df82e4ad-949e-44cb-8acf-2d1acda71798", 33 | "name": "alice", 34 | "email": "alice@example.com", 35 | "primaryOnAccounts": [ 36 | "Account::\"c943927f-d803-4f40-9a53-7740272cb969\"", 37 | "Account::\"b8ee140c-fa09-46c3-992e-099438930894\"" 38 | ] 39 | } 40 | ``` 41 | And, subsequently using the attribute within a policy: 42 | 43 | ```Cedar 44 | // Derived relationship permissions 45 | permit ( 46 | principal, 47 | action in Action::"primaryAccountHolderActions", 48 | resource 49 | )when { 50 | resource in principal.primaryOnAccounts 51 | }; 52 | ``` 53 | 54 | Conversely, the same relationship could be represented as an attribute on the resource called `primaryAccountHolders` that contains a set of users. 55 | 56 | If there are multiple relationship types between principals and resources, then these should be modeled as different attributes. For example, if accounts can also have authorized signatories, and these individuals have different permissions on the account, then this would be represented as a different attribute. 57 | 58 | In the above case, `Alice` might also be an authorized signatory on a third account. The following example shows how this could be represented: 59 | ```Cedar 60 | // Using user attributes to represent the primary account holder and authorized signatory relationships 61 | { 62 | "id": "df82e4ad-949e-44cb-8acf-2d1acda71798", 63 | "name": "alice", 64 | "email": "alice@example.com", 65 | "primaryOnAccounts": [ 66 | "Account::\"c943927f-d803-4f40-9a53-7740272cb969\"", 67 | "Account::\"b8ee140c-fa09-46c3-992e-099438930894\"" 68 | ], 69 | "authorizedSignatoryOnAccounts": [ 70 | "Account::\"661817a9-d478-4096-943d-4ef1e082d19a\"" 71 | ] 72 | } 73 | ``` 74 | 75 | The following are the corresponding policies: 76 | 77 | ```Cedar 78 | // Derived relationship permissions 79 | 80 | permit ( 81 | principal, 82 | action in Action::"primaryAccountHolderActions", 83 | resource 84 | )when { 85 | resource in principal.primaryOnAccounts 86 | }; 87 | permit ( 88 | principal, 89 | action in Action::"authorizedSignatoryActions", 90 | resource 91 | )when { 92 | resource in principal.authorizedSignatoryOnAccounts 93 | }; 94 | ``` 95 | ## Template-based relationships {#template-based} 96 | If the relationship between resources exists solely for the purpose of permissions management then it’s appropriate to store this relationship as a template-linked policy, or template. You can also think of these templates as roles that are assigned on a specific resource. 97 | 98 | For example, in a document management system, the document owner, `Alice`, may choose to grant permission to another user, `Bob`, to contribute to the document. This establishes a contributor relationship between Bob and Alice’s document. The sole purpose of this relationship is to grant permission to edit and comment on the document, and hence this relationship can be represented as a template. In these cases the recommended approach is to create a template for each type of relationship. In the following examples there are two relationship types, `Contributor` and `Reviewer`, and therefore two templates. 99 | The following templates can be used to create template-linked policies for individual users. 100 | ```Cedar 101 | // Managed relationship permissions - Contributor template 102 | permit ( 103 | principal == ?principal, 104 | action in Action::"DocumentContributorActions", 105 | resource in ?resource 106 | ); 107 | 108 | // Managed relationship permissions - Reviewer template 109 | permit ( 110 | principal == ?principal, 111 | action in Action::"DocumentReviewerActions", 112 | resource in ?resource 113 | ); 114 | ``` 115 | The following templates can be used to create template-linked policies for groups of users. The only difference from the templates for individual users is that use of the `in` operator instead of the `==`. 116 | ```Cedar 117 | // Managed relationship permissions - Contributor template 118 | permit ( 119 | principal in ?principal, 120 | action in Action::"DocumentContributorActions", 121 | resource in ?resource 122 | ); 123 | 124 | // Managed relationship permissions - Reviewer template 125 | permit ( 126 | principal in ?principal, 127 | action in Action::"DocumentReviewerActions", 128 | resource in ?resource 129 | ); 130 | ``` 131 | You can then use these templates to create policies, like the following ones, representing managed relationship permissions each time access is granted to a document. 132 | ```Cedar 133 | //Managed relationship permissions 134 | permit ( 135 | principal in User::"df82e4ad-949e-44cb-8acf-2d1acda71798", 136 | action in Action::"DocumentContributorActions", 137 | resource in Document::"c943927f-d803-4f40-9a53-7740272cb969" 138 | ); 139 | 140 | permit ( 141 | principal in UserGroup::"df82e4ad-949e-44cb-8acf-2d1acda71798", 142 | action in Action::"DocumentReviewerActions", 143 | resource == Document::"661817a9-d478-4096-943d-4ef1e082d19a" 144 | ); 145 | 146 | permit ( 147 | principal in User::"df82e4ad-949e-44cb-8acf-2d1acda71798", 148 | action in Action::"DocumentContributorActions", 149 | resource in Folder::"b8ee140c-fa09-46c3-992e-099438930894" 150 | ); 151 | ``` 152 | -------------------------------------------------------------------------------- /docs/collections/_bestpractices/bp-resources-containers.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Resource containers 4 | nav_order: 5 5 | --- 6 | 7 | # Best practice: Every resource lives in a container 8 | 9 | {: .no_toc } 10 | 11 | When you design an authorization model, every action must be associated with a particular resource. With an action such as `viewFile`, the resource that you can apply it to is intuitive: an individual file, or perhaps a collection of files within a folder. However, an operation such as `createFile` is less intuitive. When modeling the capability to create a file, what resource does it apply to? It can't be the file itself, because the file doesn’t exist yet. 12 | 13 | This is an example of the generalized problem of resource creation. Resource creation is a bootstrapping problem. There must be a way for something to have permission to create resources even when no resources exist yet. The solution is to recognize that every resource must exist within some container, and it is the container itself that acts as the anchor point for permissions. For example, if a folder already exists in the system, the ability to create a file can be modeled as a permission on that folder, since that is the location where permissions are necessary to instantiate the new resource. 14 | 15 | ```Cedar 16 | permit ( 17 | principal == User::"6688f676-1aa9-456a-acf4-228340b54e9d", 18 | action == Action::"createFile", 19 | resource == Folder::"c863f89b-461f-4fc2-b638-e5fa5f79a48b" 20 | ); 21 | ``` 22 | 23 | But what if no folder exists? Perhaps this is a brand new customer account in an application where no resources exist yet. In this situation, there is still a context that can be intuitively understood by asking: where can the customer create new files? You don't want them to be able to create files inside any random customer account. Rather, there is an implied context: the customer’s own account boundary. Therefore, the account itself represents the container for resource creation, and this can be explicitly modeled in a policy similar to the following example. 24 | 25 | ```Cedar 26 | // Grants permission to create files within an account, 27 | // or within any sub-folder inside the account. 28 | permit ( 29 | principal == User::"6688f676-1aa9-456a-acf4-228340b54e9d", 30 | action == Action::"createFile", 31 | resource in Account::"c863f89b-461f-4fc2-b638-e5fa5f79a48b" 32 | ); 33 | ``` 34 | 35 | Yet, what if no accounts exist either? You might choose to design the customer sign-up workflow so that the it creates new accounts in the system. If so, you’ll need a container to hold the outermost boundary in which the process can create the accounts. This root level container represents the system as a whole and might be named something like “system root”. However, the decision for whether this is needed, and what to name it is up to you, the application owner. 36 | 37 | For this sample application, the resulting container hierarchy would therefore appears as follows: 38 | 39 | ![\[Illustrates the hierarchy of a container.\]](images/resource-lives-in-container.png) 40 | 41 | This is one sample hierarchy. Others are valid as well. The thing to remember is that resource creation always happens within the context of a resource container. These containers can be implicit, such as an account boundary, and it can be easy to overlook them. When designing your authorization model, be sure to note these implicit assumptions so they can be formally documented and represented in the authorization model. 42 | -------------------------------------------------------------------------------- /docs/collections/_bestpractices/bp-separate-principals.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Separate principals & containers 4 | nav_order: 6 5 | --- 6 | 7 | # Best practice: Separate the principals from the resource containers 8 | {: .no_toc } 9 | 10 | When you are designing a resource hierarchy, one of the common inclinations, especially for consumer-facing applications, is to use the customer's user identity as the container for resources within a customer account. 11 | 12 | ![\[Illustrates the structure of contaier where the user ID is the container.\]](images/separate-principals-from-resources.png) 13 | 14 | We recommend that you treat this strategy as an anti-pattern. This is because there is a natural tendency in richer applications to delegate access to additional users. For example, you might choose to introduce "family" accounts, where other users can share account resources. Similarly, enterprise customers sometimes want to designate multiple members of the workforce as operators for portions of the account. You might also need to transfer ownership of an account to a different user, or merge the resources of multiple accounts together. 15 | 16 | When a user identity is used as the resource container for an account, the previous scenarios become more difficult to achieve. More alarming, if others are granted access to the account container in this approach, they might inadvertently be granted access to modify the user identity itself, such as changing Jane’s email or login credentials. 17 | 18 | Therefore, when possible to do so, a more resilient approach is to separate the principals from the resource containers, and model the connection between them by using concepts such as "admin permissions" or "ownership". 19 | 20 | ![\[Illustrates the structure of contaier where the user ID is separated from the container.\]](images/separate-principals-from-resources-2.png) 21 | 22 | Where you have an existing application that is unable to pursue this decoupled model, we recommend that you consider mimicking it as much as possible when designing an authorization model. For example, an application that possesses only a single concept named `Customer` that encapsulates the user identity, login credentials, and resources that they own, could map this to an authorization model that contains one logical entity for `Customer Identity` (containing name, email, etc) and a separate logical entity for `Customer Resources` or `Customer Account`, acting as the parent node for all the resources they own. Both entities can share the same `Id`, but with a different `Type`. 23 | 24 | ![\[Illustrates the structure of contaier where the user ID is contained in a customer identity.\]](images/separate-principals-from-resources-3.png) 25 | -------------------------------------------------------------------------------- /docs/collections/_bestpractices/bp-using-the-context.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Using the context 4 | nav_order: 9 5 | --- 6 | 7 | # Best practice: Don't use the context field to hold information about the principal, action, and resource 8 | {: .no_toc } 9 | 10 | Cedar policy statements include four variables named principal, action, resource, and context. Each variable should be used for its purpose. For example, information about the resource should not be populated in the principal. 11 | 12 | We recommend that you avoid using the context field to store information that is more naturally associated with the principal, action or resource. The context field is intended for information unique to a particular request, such as http headers, time of day, the caller’s authentication or device posture, or information about the request parameters. 13 | 14 | In addition, context can be used for information that is not naturally affiliated with other entities, such as whether an open support case exists that allows the principal to act upon the resource. 15 | -------------------------------------------------------------------------------- /docs/collections/_bestpractices/images/AVP-BASICS.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_bestpractices/images/AVP-BASICS.jpg -------------------------------------------------------------------------------- /docs/collections/_bestpractices/images/Cedar 1 - black.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_bestpractices/images/Cedar 1 - black.png -------------------------------------------------------------------------------- /docs/collections/_bestpractices/images/Cedar 1 - white.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_bestpractices/images/Cedar 1 - white.png -------------------------------------------------------------------------------- /docs/collections/_bestpractices/images/Cedar 2 - black.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_bestpractices/images/Cedar 2 - black.png -------------------------------------------------------------------------------- /docs/collections/_bestpractices/images/Cedar 2 - green.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_bestpractices/images/Cedar 2 - green.png -------------------------------------------------------------------------------- /docs/collections/_bestpractices/images/Cedar 2 - white.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_bestpractices/images/Cedar 2 - white.png -------------------------------------------------------------------------------- /docs/collections/_bestpractices/images/Cedar1-green.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_bestpractices/images/Cedar1-green.png -------------------------------------------------------------------------------- /docs/collections/_bestpractices/images/InvertedGroupHierarchy.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_bestpractices/images/InvertedGroupHierarchy.jpg -------------------------------------------------------------------------------- /docs/collections/_bestpractices/images/PhotoFlash.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_bestpractices/images/PhotoFlash.png -------------------------------------------------------------------------------- /docs/collections/_bestpractices/images/ResourceHierarchy.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_bestpractices/images/ResourceHierarchy.jpg -------------------------------------------------------------------------------- /docs/collections/_bestpractices/images/entities.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_bestpractices/images/entities.png -------------------------------------------------------------------------------- /docs/collections/_bestpractices/images/hierarchy.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_bestpractices/images/hierarchy.png -------------------------------------------------------------------------------- /docs/collections/_bestpractices/images/quotas-transitive-parents.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_bestpractices/images/quotas-transitive-parents.png -------------------------------------------------------------------------------- /docs/collections/_bestpractices/images/resource-lives-in-container.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_bestpractices/images/resource-lives-in-container.png -------------------------------------------------------------------------------- /docs/collections/_bestpractices/images/security-of-cedar.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_bestpractices/images/security-of-cedar.png -------------------------------------------------------------------------------- /docs/collections/_bestpractices/images/separate-principals-from-resources-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_bestpractices/images/separate-principals-from-resources-2.png -------------------------------------------------------------------------------- /docs/collections/_bestpractices/images/separate-principals-from-resources-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_bestpractices/images/separate-principals-from-resources-3.png -------------------------------------------------------------------------------- /docs/collections/_bestpractices/images/separate-principals-from-resources.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_bestpractices/images/separate-principals-from-resources.png -------------------------------------------------------------------------------- /docs/collections/_bestpractices/images/source/entities.drawio: -------------------------------------------------------------------------------- 1 | 7VrbctowEP0aPybjO+kjlyTNQ2fSYTqlfckIW7GVyJYri1u/vitbxhcMgYQESHlCeyStdlfnCNmgWf1ofstREn5jPqaaqftzzRpopml0dAc+JLLIkY6tgIATXw0qgSH5ixWoK3RCfJzWBgrGqCBJHfRYHGNP1DDEOZvVhz0yWl81QQFeAYYeoqvoT+KLMEevHL3Ev2IShMXKhq56IlQMVkAaIp/NKpB1rVl9zpjIW9G8j6ksXlGXfN7Nmt5lYBzHYpsJXnLXZc73CN+F9kOfGaOn0e8L5WWK6EQlrJkuihLN6sXjVH6IRQI93R8p5tBFYaneWLYC2WoOxnKxriYjcf9MZGa9JxTj0mp1kSE+mTahNEHxupWQ57GJTFyu1i0NaW9eGirUcFzAtRCyLROLggccFvCxLKUO3bOQCDxMkCd7Z8B8wEIRUbAMGRwlQQxtih9LZ1PMBZ6v3TxjSQnQEmYRFnwBQ5RszCvFollJQsNWWFghoKswpHgfLF2V1ICGYscOTDHbmFLZpkqxiopnVbpI8zLJfYoZjxCtbUnr5tY5V+t6YRclr94YyTvl1CKNMRvX5h0i0Yzz+8xzG2E2Ez8BAVruoQVoHUyAn0ZwQAtv+2+Ek5bY+lSPWGS2fWiR2WeRvVVkTyyM/w+Nrc30iCXmmIeWmPPxEruFoiefSmPwZPPwiCJCF6cvNTaL4QTMpmRn4bZPcceoMjXBLN4CHM3t0T2rbk+q4wTHfnqW3RHKzm7I7vD3yc5ZdvuRncdmjD9jfhbeMQqv+X13+Fum0fZmu1E07Ad4qEzGRcgCFiN6XaLVosGh35W/J4A5psx7lhAdZ7YsHfFg60EQAnFRjItZjPOZN4QWflLB2TPuM8p4FoXl2E7PtaGnvod4TsSoWBvavyR+6ShrMK8MGywKI4bSjapGZZY0y2mZVczLKyPLsXn/oXpswj28oe6qylCGAIuXngJW+VTlS8EpjikSZFqPrY0wyt09IxD1kptGnZqu3qBcnpKaVP39pOnnJUd5ziuOMvouU3wDo9vewJ8Z/e6MtrZktPtxjHYa15zXUrqpjRVH703pttdtJ0Xpgp4X+qXeMXbjaGbdY06gjPIasCNxj4iQlt143P3ySkJanQYhO9sREjYTLSrDEjkg3RBwpz3gXeMq9ZBHsF91tL0pOyl1vOLA3+PBbZ/ggdy8Rzv7OpDBLP9qkg8v/7BjXf8D -------------------------------------------------------------------------------- /docs/collections/_bestpractices/images/structure-of-policy.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_bestpractices/images/structure-of-policy.png -------------------------------------------------------------------------------- /docs/collections/_bestpractices/images/transitive-attributes-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_bestpractices/images/transitive-attributes-2.png -------------------------------------------------------------------------------- /docs/collections/_bestpractices/images/transitive-attributes-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_bestpractices/images/transitive-attributes-3.png -------------------------------------------------------------------------------- /docs/collections/_bestpractices/images/transitive-attributes.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_bestpractices/images/transitive-attributes.png -------------------------------------------------------------------------------- /docs/collections/_other/doc-history.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Document history 4 | nav_order: 14 5 | --- 6 | 7 | # History for the Cedar Policy Language {#doc-history} 8 | {: .no_toc } 9 | 10 | ## History of the Cedar language 11 | 12 | The following table tracks changes to the Cedar language version. The language version is different from the SDK version (which corresponds to the `cedar-policy` version on [crates.io](https://crates.io/crates/cedar-policy)) because a breaking change for the Cedar Rust API may or may not be a breaking change for the Cedar language. See the [SDK changelog](https://github.com/cedar-policy/cedar/blob/main/cedar-policy/CHANGELOG.md) for details about what is included in different SDK versions. We recommend using the latest SDK version that supports your desired language version since later SDK versions may contain important bug fixes and improvements to usability. 13 | 14 | | Cedar
Version | Description | Cedar SDK
Version(s) | Date | 15 | | --- | --- | --- | --- | 16 | | 4.3 | enumerated entity types [rfc#53](https://github.com/cedar-policy/rfcs/blob/main/text/0053-enum-entities.md)
`datetime` extension [rfc#80](https://github.com/strongdm/cedar-rfcs/blob/datetime-rfc/text/0080-datetime-extension.md)
entity slice validation [rfc#76](https://github.com/cedar-policy/rfcs/blob/main/text/0076-entity-slice-validation.md) | 4.4.0 - 4.4.1 | April 23, 2025 17 | | 4.2 | `isEmpty` operator [cedar#1358](https://github.com/cedar-policy/cedar/pull/1358)
extended `has` operator [rfc#62](https://github.com/cedar-policy/rfcs/blob/main/text/0062-extended-has.md)
`datetime` extension (experimental) [rfc#80](https://github.com/strongdm/cedar-rfcs/blob/datetime-rfc/text/0080-datetime-extension.md)
schema annotations [rfc#48](https://github.com/cedar-policy/rfcs/blob/main/text/0048-schema-annotations.md) | 4.3.0 - 4.3.3 | January 21, 2025 18 | | 4.1 | Entity tags [rfc#82](https://github.com/cedar-policy/rfcs/blob/main/text/0082-entity-tags.md)
Annotations without values [cedar#1231](https://github.com/cedar-policy/cedar/pull/1231) | 4.2.0 - 4.2.2 | October 7, 2024 19 | | 4.0 | Reserve `__cedar` identifier for internal use [rfc#52](https://github.com/cedar-policy/rfcs/blob/main/text/0052-reserved-namespaces.md)
Remove unspecified entities [rfc#55](https://github.com/cedar-policy/rfcs/blob/main/text/0055-remove-unspecified.md)
Disallow shadowing definitions in the empty namespace [rfc#70](https://github.com/cedar-policy/rfcs/blob/main/text/0070-disallow-empty-namespace-shadowing.md)
Allow `EntityOrCommon` field in JSON schema [cedar#1060](https://github.com/cedar-policy/cedar/pull/1060)
Disallow `Bool`, `Boolean`, `Entity`, `Extension`, `Long`, `Record`, `Set`, and `String` as common type names in schemas [cedar#1150](https://github.com/cedar-policy/cedar/pull/1150) | 4.0.0 - 4.1.0 | September 16, 2024 | 20 | | 3.4 | JSON format for policy sets [cedar#549](https://github.com/cedar-policy/cedar/issues/549) | 3.3.0 - 3.4.0 | August 19, 2024 | 21 | | 3.3 | References between common types [cedar#154](https://github.com/cedar-policy/cedar/issues/154) | 3.2.0 - 3.2.4 | May 17, 2024 | 22 | | 3.2 | General multiplication operator [rfc#57](https://github.com/cedar-policy/rfcs/blob/main/text/0057-general-multiplication.md) | 3.1.2 - 3.1.4 | March 29, 2024 | 23 | | 3.1 | Cedar schema format [rfc#24](https://github.com/cedar-policy/rfcs/blob/main/text/0024-schema-syntax.md) | 3.1.0 - 3.1.1 | March 8, 2024 | 24 | | 3.0 | `is` operator [rfc#5](https://github.com/cedar-policy/rfcs/blob/main/text/0005-is-operator.md)
Stricter validation [rfc#19](https://github.com/cedar-policy/rfcs/blob/main/text/0019-stricter-validation.md)
Disallow duplicate keys in records [rfc#20](https://github.com/cedar-policy/rfcs/blob/main/text/0020-unique-record-keys.md)
Request validation [cedar#191](https://github.com/cedar-policy/cedar/issues/191)
Entity validation [cedar#360](https://github.com/cedar-policy/cedar/pull/360) | 3.0.0 - 3.0.1 | December 15, 2023 | 25 | | 2.2 | General multiplication operator (backport to 2.x) [rfc#57](https://github.com/cedar-policy/rfcs/blob/main/text/0057-general-multiplication.md) | 2.4.5 - 2.5.0 | April 1, 2024 | 26 | | 2.1 | Disallow whitespace in namespaces [rfc#9](https://github.com/cedar-policy/rfcs/blob/main/text/0009-disallow-whitespace-in-entityuid.md) | 2.3.0 - 2.4.4 | June 29, 2023 | 27 | | 2.0 | Initial release of the Cedar Policy Language | 2.0.0 - 2.2.0 | May 10, 2023 | 28 | 29 | ## Document history for the Cedar Policy Language Guide 30 | The following table describes major documentation updates for Cedar. 31 | 32 | | Description | Date | 33 | | --- | --- | 34 | | Added [JSON policy set format](../policies/json-format.html#policy-set-format) sub-topic | August 19, 2024 | 35 | | Added [Cedar schema format](../schema/human-readable-schema.html) topic | February 21, 2024 | 36 | | Added [`is` operator](../policies/syntax-operators.html#operator-is) sub-topic | December 15, 2023 | 37 | | Added [Entities & context syntax](../auth/entities-syntax.html) topic | July 27, 2023 | 38 | | Added [Schema grammar](../schema/schema-grammar.html) topic | July 17, 2023 | 39 | | Added [JSON policy format](../policies/json-format.html) topic | July 14, 2023 | 40 | | Added [Best Practices](../overview/best-practices.html) topics | July 14, 2023 | 41 | | Initial release of the Cedar Policy Language Guide | May 10, 2023 | 42 | -------------------------------------------------------------------------------- /docs/collections/_other/images/AVP-BASICS.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_other/images/AVP-BASICS.jpg -------------------------------------------------------------------------------- /docs/collections/_other/images/Cedar 1 - black.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_other/images/Cedar 1 - black.png -------------------------------------------------------------------------------- /docs/collections/_other/images/Cedar 1 - white.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_other/images/Cedar 1 - white.png -------------------------------------------------------------------------------- /docs/collections/_other/images/Cedar 2 - black.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_other/images/Cedar 2 - black.png -------------------------------------------------------------------------------- /docs/collections/_other/images/Cedar 2 - green.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_other/images/Cedar 2 - green.png -------------------------------------------------------------------------------- /docs/collections/_other/images/Cedar 2 - white.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_other/images/Cedar 2 - white.png -------------------------------------------------------------------------------- /docs/collections/_other/images/Cedar1-green.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_other/images/Cedar1-green.png -------------------------------------------------------------------------------- /docs/collections/_other/images/PhotoFlash.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_other/images/PhotoFlash.png -------------------------------------------------------------------------------- /docs/collections/_other/images/entities.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_other/images/entities.png -------------------------------------------------------------------------------- /docs/collections/_other/images/hierarchy.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_other/images/hierarchy.png -------------------------------------------------------------------------------- /docs/collections/_other/images/quotas-transitive-parents.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_other/images/quotas-transitive-parents.png -------------------------------------------------------------------------------- /docs/collections/_other/images/resource-lives-in-container.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_other/images/resource-lives-in-container.png -------------------------------------------------------------------------------- /docs/collections/_other/images/security-of-cedar.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_other/images/security-of-cedar.png -------------------------------------------------------------------------------- /docs/collections/_other/images/separate-principals-from-resources-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_other/images/separate-principals-from-resources-2.png -------------------------------------------------------------------------------- /docs/collections/_other/images/separate-principals-from-resources-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_other/images/separate-principals-from-resources-3.png -------------------------------------------------------------------------------- /docs/collections/_other/images/separate-principals-from-resources.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_other/images/separate-principals-from-resources.png -------------------------------------------------------------------------------- /docs/collections/_other/images/source/entities.drawio: -------------------------------------------------------------------------------- 1 | 7VrbctowEP0aPybjO+kjlyTNQ2fSYTqlfckIW7GVyJYri1u/vitbxhcMgYQESHlCeyStdlfnCNmgWf1ofstREn5jPqaaqftzzRpopml0dAc+JLLIkY6tgIATXw0qgSH5ixWoK3RCfJzWBgrGqCBJHfRYHGNP1DDEOZvVhz0yWl81QQFeAYYeoqvoT+KLMEevHL3Ev2IShMXKhq56IlQMVkAaIp/NKpB1rVl9zpjIW9G8j6ksXlGXfN7Nmt5lYBzHYpsJXnLXZc73CN+F9kOfGaOn0e8L5WWK6EQlrJkuihLN6sXjVH6IRQI93R8p5tBFYaneWLYC2WoOxnKxriYjcf9MZGa9JxTj0mp1kSE+mTahNEHxupWQ57GJTFyu1i0NaW9eGirUcFzAtRCyLROLggccFvCxLKUO3bOQCDxMkCd7Z8B8wEIRUbAMGRwlQQxtih9LZ1PMBZ6v3TxjSQnQEmYRFnwBQ5RszCvFollJQsNWWFghoKswpHgfLF2V1ICGYscOTDHbmFLZpkqxiopnVbpI8zLJfYoZjxCtbUnr5tY5V+t6YRclr94YyTvl1CKNMRvX5h0i0Yzz+8xzG2E2Ez8BAVruoQVoHUyAn0ZwQAtv+2+Ek5bY+lSPWGS2fWiR2WeRvVVkTyyM/w+Nrc30iCXmmIeWmPPxEruFoiefSmPwZPPwiCJCF6cvNTaL4QTMpmRn4bZPcceoMjXBLN4CHM3t0T2rbk+q4wTHfnqW3RHKzm7I7vD3yc5ZdvuRncdmjD9jfhbeMQqv+X13+Fum0fZmu1E07Ad4qEzGRcgCFiN6XaLVosGh35W/J4A5psx7lhAdZ7YsHfFg60EQAnFRjItZjPOZN4QWflLB2TPuM8p4FoXl2E7PtaGnvod4TsSoWBvavyR+6ShrMK8MGywKI4bSjapGZZY0y2mZVczLKyPLsXn/oXpswj28oe6qylCGAIuXngJW+VTlS8EpjikSZFqPrY0wyt09IxD1kptGnZqu3qBcnpKaVP39pOnnJUd5ziuOMvouU3wDo9vewJ8Z/e6MtrZktPtxjHYa15zXUrqpjRVH703pttdtJ0Xpgp4X+qXeMXbjaGbdY06gjPIasCNxj4iQlt143P3ySkJanQYhO9sREjYTLSrDEjkg3RBwpz3gXeMq9ZBHsF91tL0pOyl1vOLA3+PBbZ/ggdy8Rzv7OpDBLP9qkg8v/7BjXf8D -------------------------------------------------------------------------------- /docs/collections/_other/images/structure-of-policy.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_other/images/structure-of-policy.png -------------------------------------------------------------------------------- /docs/collections/_other/images/transitive-attributes-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_other/images/transitive-attributes-2.png -------------------------------------------------------------------------------- /docs/collections/_other/images/transitive-attributes-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_other/images/transitive-attributes-3.png -------------------------------------------------------------------------------- /docs/collections/_other/images/transitive-attributes.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_other/images/transitive-attributes.png -------------------------------------------------------------------------------- /docs/collections/_overview/dropped-topics.zip: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_overview/dropped-topics.zip -------------------------------------------------------------------------------- /docs/collections/_overview/images/AVP-BASICS.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_overview/images/AVP-BASICS.jpg -------------------------------------------------------------------------------- /docs/collections/_overview/images/Cedar 1 - black.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_overview/images/Cedar 1 - black.png -------------------------------------------------------------------------------- /docs/collections/_overview/images/Cedar 1 - white.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_overview/images/Cedar 1 - white.png -------------------------------------------------------------------------------- /docs/collections/_overview/images/Cedar 2 - black.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_overview/images/Cedar 2 - black.png -------------------------------------------------------------------------------- /docs/collections/_overview/images/Cedar 2 - green.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_overview/images/Cedar 2 - green.png -------------------------------------------------------------------------------- /docs/collections/_overview/images/Cedar 2 - white.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_overview/images/Cedar 2 - white.png -------------------------------------------------------------------------------- /docs/collections/_overview/images/Cedar1-green.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_overview/images/Cedar1-green.png -------------------------------------------------------------------------------- /docs/collections/_overview/images/InvertedGroupHierarchy.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_overview/images/InvertedGroupHierarchy.jpg -------------------------------------------------------------------------------- /docs/collections/_overview/images/PhotoFlash.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_overview/images/PhotoFlash.png -------------------------------------------------------------------------------- /docs/collections/_overview/images/ResourceHierarchy.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_overview/images/ResourceHierarchy.jpg -------------------------------------------------------------------------------- /docs/collections/_overview/images/entities.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_overview/images/entities.png -------------------------------------------------------------------------------- /docs/collections/_overview/images/hierarchy.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_overview/images/hierarchy.png -------------------------------------------------------------------------------- /docs/collections/_overview/images/quotas-transitive-parents.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_overview/images/quotas-transitive-parents.png -------------------------------------------------------------------------------- /docs/collections/_overview/images/resource-lives-in-container.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_overview/images/resource-lives-in-container.png -------------------------------------------------------------------------------- /docs/collections/_overview/images/security-of-cedar.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_overview/images/security-of-cedar.png -------------------------------------------------------------------------------- /docs/collections/_overview/images/separate-principals-from-resources-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_overview/images/separate-principals-from-resources-2.png -------------------------------------------------------------------------------- /docs/collections/_overview/images/separate-principals-from-resources-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_overview/images/separate-principals-from-resources-3.png -------------------------------------------------------------------------------- /docs/collections/_overview/images/separate-principals-from-resources.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_overview/images/separate-principals-from-resources.png -------------------------------------------------------------------------------- /docs/collections/_overview/images/source/entities.drawio: -------------------------------------------------------------------------------- 1 | 7VrbctowEP0aPybjO+kjlyTNQ2fSYTqlfckIW7GVyJYri1u/vitbxhcMgYQESHlCeyStdlfnCNmgWf1ofstREn5jPqaaqftzzRpopml0dAc+JLLIkY6tgIATXw0qgSH5ixWoK3RCfJzWBgrGqCBJHfRYHGNP1DDEOZvVhz0yWl81QQFeAYYeoqvoT+KLMEevHL3Ev2IShMXKhq56IlQMVkAaIp/NKpB1rVl9zpjIW9G8j6ksXlGXfN7Nmt5lYBzHYpsJXnLXZc73CN+F9kOfGaOn0e8L5WWK6EQlrJkuihLN6sXjVH6IRQI93R8p5tBFYaneWLYC2WoOxnKxriYjcf9MZGa9JxTj0mp1kSE+mTahNEHxupWQ57GJTFyu1i0NaW9eGirUcFzAtRCyLROLggccFvCxLKUO3bOQCDxMkCd7Z8B8wEIRUbAMGRwlQQxtih9LZ1PMBZ6v3TxjSQnQEmYRFnwBQ5RszCvFollJQsNWWFghoKswpHgfLF2V1ICGYscOTDHbmFLZpkqxiopnVbpI8zLJfYoZjxCtbUnr5tY5V+t6YRclr94YyTvl1CKNMRvX5h0i0Yzz+8xzG2E2Ez8BAVruoQVoHUyAn0ZwQAtv+2+Ek5bY+lSPWGS2fWiR2WeRvVVkTyyM/w+Nrc30iCXmmIeWmPPxEruFoiefSmPwZPPwiCJCF6cvNTaL4QTMpmRn4bZPcceoMjXBLN4CHM3t0T2rbk+q4wTHfnqW3RHKzm7I7vD3yc5ZdvuRncdmjD9jfhbeMQqv+X13+Fum0fZmu1E07Ad4qEzGRcgCFiN6XaLVosGh35W/J4A5psx7lhAdZ7YsHfFg60EQAnFRjItZjPOZN4QWflLB2TPuM8p4FoXl2E7PtaGnvod4TsSoWBvavyR+6ShrMK8MGywKI4bSjapGZZY0y2mZVczLKyPLsXn/oXpswj28oe6qylCGAIuXngJW+VTlS8EpjikSZFqPrY0wyt09IxD1kptGnZqu3qBcnpKaVP39pOnnJUd5ziuOMvouU3wDo9vewJ8Z/e6MtrZktPtxjHYa15zXUrqpjRVH703pttdtJ0Xpgp4X+qXeMXbjaGbdY06gjPIasCNxj4iQlt143P3ySkJanQYhO9sREjYTLSrDEjkg3RBwpz3gXeMq9ZBHsF91tL0pOyl1vOLA3+PBbZ/ggdy8Rzv7OpDBLP9qkg8v/7BjXf8D -------------------------------------------------------------------------------- /docs/collections/_overview/images/structure-of-policy.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_overview/images/structure-of-policy.png -------------------------------------------------------------------------------- /docs/collections/_overview/images/transitive-attributes-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_overview/images/transitive-attributes-2.png -------------------------------------------------------------------------------- /docs/collections/_overview/images/transitive-attributes-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_overview/images/transitive-attributes-3.png -------------------------------------------------------------------------------- /docs/collections/_overview/images/transitive-attributes.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_overview/images/transitive-attributes.png -------------------------------------------------------------------------------- /docs/collections/_overview/resources.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Additional resources 4 | nav_order: 5 5 | --- 6 | 7 | # Start using Cedar {#additional-resources} 8 | {: .no_toc } 9 | 10 | If you want to see Cedar in action, implement Cedar as a service, or work with an example application while you learn, check out these additional resources. 11 | 12 | + Build policies and experiment with Cedar authorization with the [Cedar playground](https://www.cedarpolicy.com/en/playground). 13 | + Set up an example application with [cedar-examples on GitHub](https://github.com/cedar-policy/cedar-examples/). For an example that doubles as a beginning tutorial, start with [tinytodo](https://github.com/cedar-policy/cedar-examples/tree/release/3.2.x/tinytodo). 14 | + Create a managed Cedar policy store with [Amazon Verified Permissions](https://aws.amazon.com/verified-permissions/). 15 | + Join the [cedar-policy Slack](https://communityinviter.com/apps/cedar-policy/cedar-policy-language). 16 | 17 | For more links, see [cedar-awesome on GitHub](https://github.com/cedar-policy/cedar-awesome). 18 | -------------------------------------------------------------------------------- /docs/collections/_overview/scenario.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Example scenario 4 | nav_order: 4 5 | --- 6 | 7 | # Cedar example scenario used in this guide {#scenario} 8 | {: .no_toc } 9 | 10 | **Conventions used in this guide** 11 | In this guide, entity type names are always spelled using *PascalCase*, with the first letter of each word capitalized. For example, `UserGroup`. 12 | Individual entity and attribute names are spelled using *camelCase*, with only the first letter of the second and following words capitalized. For example, `janeFriends`. 13 | 14 | The examples in this guide use the following hypothetical photo sharing application, called *PhotoFlash*. This application provides users with the ability to store, organize, and share their photos. Users can upload photos to their *PhotoFlash* account and organize them into albums. Albums can be nested in other albums and photos can belong to multiple albums. Users can also add custom metadata, such as the names of people visible, to each photo in the form of tags. Then, users can search for photos based on the attached metadata, such as searching for any photos that were taken after a certain date or at a certain geographic location. 15 | 16 | *PhotoFlash* users can share their photos and albums with other *PhotoFlash* users or user groups. In the following illustration, a user named **jane** created groups to represent her family \(`janeFamily`\), friends \(`janeFriends`\), and coworkers \(`janeCoworkers`\). She can then populate those groups with other *PhotoFlash* users, and specify how members of those groups can access her photos and albums. User groups are as flexible as albums; they can be nested, and a user can belong to multiple groups. 17 | 18 | ![\[A user named Jane has an account that contains her albums and photos, and groups of users that she created.\]](../../images/AVP-BASICS.jpg) 19 | 20 | {: .important } 21 | >This guide includes examples that use simple entity identifiers, such as `jane` or `bob` for the name of an entity of type `User`. This approach makes the examples more readable. 22 | > 23 | >However, in a production system, it's critical for security reasons that you use unique values that can't be reused. We recommend that you use values like [universally unique identifiers \(UUIDs\)](https://wikipedia.org/wiki/Universally_unique_identifier). For example, a user `jane` leaves the company. Later, you let someone else use the name `jane`. That new user gets access automatically to everything granted by policies that still reference `User::"jane"`. Cedar can't distinguish between the new user and the previous user. 24 | > 25 | > This warning applies to both principal and resource identifiers. Always use identifiers that are guaranteed unique and never reused to ensure that you don't grant access unintentionally because of the presence of an old identifier in a policy. 26 | > 27 | >Where this guide does show a UUID for an entity, it also shows the entity's display name as a comment to make the policies easier to understand. For example: 28 | > 29 | >```cedar 30 | >principal == User::"a1b2c3d4-e5f6-a1b2-c3d4-EXAMPLE11111", // alice 31 | >``` 32 | 33 | The photos have metadata, such as a `created` date timestamp, and each photo can optionally have user-defined tags attached, such as the tags `private`, `work`, and `fun`. 34 | 35 | Based on group membership, Jane can allow certain users to perform specific actions on her *PhotoFlash* resources. For example, the following policy allows members of the group `janeFriends` to view and comment on any photo in the album `janeTrips`. Because the `in` operator works transitively, it also applies to any photos in albums that are nested within the album `janeTrips`. Therefore, this example also allows access to the pictures in albums `janeVacation` and `conference`. 36 | 37 | ```cedar 38 | // Jane's friends can view all photos in her janeTrips album 39 | 40 | permit ( 41 | principal in Group::"janeFriends", 42 | action in [Action::"view", Action::"comment"], 43 | resource in Album::"janeTrips" 44 | ); 45 | ``` 46 | 47 | Any action that isn't explicitly permitted is denied. You can also choose to *always* deny some actions as a matter of service-wide security or design constraints, even if a user explicitly tries to allow those actions. For example, the following policy ensures that no user other than the owner of the account that contains the resource can perform any action if that resource is tagged `private`. The following policy doesn't specify any specific principal, action, or resource. The policy matches *any* request automatically and denies access if either the `when` or `unless` expressions evaluate to `true` for that request. 48 | 49 | ```cedar 50 | // Only the owner can access any resource tagged "private" 51 | 52 | forbid ( principal, action, resource ) 53 | when { resource.tags.contains("private") } // assumes that resource has "tags" 54 | unless { resource in principal.account }; // assumes that principal has "account" 55 | ``` 56 | 57 | The order of the `when` and `unless` clauses matters in the case where one or more of them generate errors. Cedar evaluates the `when` and `unless` clauses in the order in which they appear in the policy. In the previous example, consider a scenario where the `when` and `unless` clauses generate separate errors. The order determines which error you actually see. 58 | -------------------------------------------------------------------------------- /docs/collections/_policies/images/AVP-BASICS.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_policies/images/AVP-BASICS.jpg -------------------------------------------------------------------------------- /docs/collections/_policies/images/Cedar 1 - black.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_policies/images/Cedar 1 - black.png -------------------------------------------------------------------------------- /docs/collections/_policies/images/Cedar 1 - white.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_policies/images/Cedar 1 - white.png -------------------------------------------------------------------------------- /docs/collections/_policies/images/Cedar 2 - black.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_policies/images/Cedar 2 - black.png -------------------------------------------------------------------------------- /docs/collections/_policies/images/Cedar 2 - green.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_policies/images/Cedar 2 - green.png -------------------------------------------------------------------------------- /docs/collections/_policies/images/Cedar 2 - white.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_policies/images/Cedar 2 - white.png -------------------------------------------------------------------------------- /docs/collections/_policies/images/Cedar1-green.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_policies/images/Cedar1-green.png -------------------------------------------------------------------------------- /docs/collections/_policies/images/PhotoFlash.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_policies/images/PhotoFlash.png -------------------------------------------------------------------------------- /docs/collections/_policies/images/entities.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_policies/images/entities.png -------------------------------------------------------------------------------- /docs/collections/_policies/images/hierarchy.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_policies/images/hierarchy.png -------------------------------------------------------------------------------- /docs/collections/_policies/images/quotas-transitive-parents.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_policies/images/quotas-transitive-parents.png -------------------------------------------------------------------------------- /docs/collections/_policies/images/resource-lives-in-container.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_policies/images/resource-lives-in-container.png -------------------------------------------------------------------------------- /docs/collections/_policies/images/security-of-cedar.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_policies/images/security-of-cedar.png -------------------------------------------------------------------------------- /docs/collections/_policies/images/separate-principals-from-resources-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_policies/images/separate-principals-from-resources-2.png -------------------------------------------------------------------------------- /docs/collections/_policies/images/separate-principals-from-resources-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_policies/images/separate-principals-from-resources-3.png -------------------------------------------------------------------------------- /docs/collections/_policies/images/separate-principals-from-resources.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_policies/images/separate-principals-from-resources.png -------------------------------------------------------------------------------- /docs/collections/_policies/images/source/entities.drawio: -------------------------------------------------------------------------------- 1 | 7VrbctowEP0aPybjO+kjlyTNQ2fSYTqlfckIW7GVyJYri1u/vitbxhcMgYQESHlCeyStdlfnCNmgWf1ofstREn5jPqaaqftzzRpopml0dAc+JLLIkY6tgIATXw0qgSH5ixWoK3RCfJzWBgrGqCBJHfRYHGNP1DDEOZvVhz0yWl81QQFeAYYeoqvoT+KLMEevHL3Ev2IShMXKhq56IlQMVkAaIp/NKpB1rVl9zpjIW9G8j6ksXlGXfN7Nmt5lYBzHYpsJXnLXZc73CN+F9kOfGaOn0e8L5WWK6EQlrJkuihLN6sXjVH6IRQI93R8p5tBFYaneWLYC2WoOxnKxriYjcf9MZGa9JxTj0mp1kSE+mTahNEHxupWQ57GJTFyu1i0NaW9eGirUcFzAtRCyLROLggccFvCxLKUO3bOQCDxMkCd7Z8B8wEIRUbAMGRwlQQxtih9LZ1PMBZ6v3TxjSQnQEmYRFnwBQ5RszCvFollJQsNWWFghoKswpHgfLF2V1ICGYscOTDHbmFLZpkqxiopnVbpI8zLJfYoZjxCtbUnr5tY5V+t6YRclr94YyTvl1CKNMRvX5h0i0Yzz+8xzG2E2Ez8BAVruoQVoHUyAn0ZwQAtv+2+Ek5bY+lSPWGS2fWiR2WeRvVVkTyyM/w+Nrc30iCXmmIeWmPPxEruFoiefSmPwZPPwiCJCF6cvNTaL4QTMpmRn4bZPcceoMjXBLN4CHM3t0T2rbk+q4wTHfnqW3RHKzm7I7vD3yc5ZdvuRncdmjD9jfhbeMQqv+X13+Fum0fZmu1E07Ad4qEzGRcgCFiN6XaLVosGh35W/J4A5psx7lhAdZ7YsHfFg60EQAnFRjItZjPOZN4QWflLB2TPuM8p4FoXl2E7PtaGnvod4TsSoWBvavyR+6ShrMK8MGywKI4bSjapGZZY0y2mZVczLKyPLsXn/oXpswj28oe6qylCGAIuXngJW+VTlS8EpjikSZFqPrY0wyt09IxD1kptGnZqu3qBcnpKaVP39pOnnJUd5ziuOMvouU3wDo9vewJ8Z/e6MtrZktPtxjHYa15zXUrqpjRVH703pttdtJ0Xpgp4X+qXeMXbjaGbdY06gjPIasCNxj4iQlt143P3ySkJanQYhO9sREjYTLSrDEjkg3RBwpz3gXeMq9ZBHsF91tL0pOyl1vOLA3+PBbZ/ggdy8Rzv7OpDBLP9qkg8v/7BjXf8D -------------------------------------------------------------------------------- /docs/collections/_policies/images/structure-of-policy.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_policies/images/structure-of-policy.png -------------------------------------------------------------------------------- /docs/collections/_policies/images/transitive-attributes-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_policies/images/transitive-attributes-2.png -------------------------------------------------------------------------------- /docs/collections/_policies/images/transitive-attributes-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_policies/images/transitive-attributes-3.png -------------------------------------------------------------------------------- /docs/collections/_policies/images/transitive-attributes.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_policies/images/transitive-attributes.png -------------------------------------------------------------------------------- /docs/collections/_policies/syntax-grammar.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Policy grammar 4 | nav_order: 6 5 | --- 6 | 7 | 8 | # Grammar for Cedar syntax {#syntax-grammar} 9 | {: .no_toc } 10 | 11 | This topic describes the grammar specification for policies in the Cedar Policy Language. This grammar uses the following symbols: 12 | 13 | + A vertical bar `|` designates alternatives. Only one alternative can be used. 14 | + Brackets `[ ]` designate an optional element. 15 | + Parentheses `( )` designate grouping 16 | + Braces `{ }` designate repetition of an element zero or more times. 17 | 18 | Capitalized words represent grammar constructs, and lexical tokens are displayed in all-caps. 19 | 20 | Tokens are defined using regular expressions: 21 | 22 | + Brackets `[ ]` represent a range of characters. 23 | + A vertical bar `|` designates alternatives. 24 | + An asterisk `*` represents zero or more occurrences of an element. 25 | + A plus sign `+` represents one or more occurrences of an element. 26 | + A question mark `?` represents exactly zero or one occurrences of an element. 27 | + A tilde `~` represents the complement of the following element. 28 | + A hyphen `-` represents difference. 29 | + Single quotation marks `' '` surround elements that must be entered literally as shown. 30 | 31 | The grammar ignores whitespace and comments. 32 | 33 | ## `Policy` {#grammar-policy} 34 | 35 | A policy consists of optional 'Annotation' entries, an `Effect`, a `Scope` in parentheses `( )`, and an optional set of `Conditions` in braces `{ }`. 36 | 37 | A policy must always end with a semicolon `;`. 38 | 39 | ``` 40 | Policy ::= {Annotation} Effect '(' Scope ')' {Conditions} ';' 41 | ``` 42 | 43 | ## `Effect` {#grammar-effect} 44 | 45 | The `Effect` element of a policy is either the word `permit` or `forbid`. 46 | 47 | ``` 48 | Effect ::= 'permit' | 'forbid' 49 | ``` 50 | 51 | ## `Scope` {#grammar-scope} 52 | 53 | The `Scope` element of a policy must include a `Principal` entity, an `Action` entity, and a `Resource` entity. 54 | 55 | ``` 56 | Scope ::= Principal ',' Action ',' Resource 57 | ``` 58 | 59 | ## `Principal` {#grammar-principal} 60 | 61 | The `Principal` element consists of the `principal` keyword. If specified by itself, the policy statement matches *any* principal. 62 | 63 | Optionally, the keyword can be followed by either the [`in`](../policies/syntax-operators.html#operator-in), [`==`](../policies/syntax-operators.html#operator-equality), or [`is`](../_policies/syntax-operators.html#operator-is) operator. 64 | An `is` operator may appear together with an `in` operators, but not an `==` operator. 65 | The `in` and `==` operators are followed by either an `Entity`, or the `?principal` placeholder when used in a policy template. 66 | 67 | ``` 68 | Principal ::= 'principal' [(['is' PATH] ['in' (Entity | '?principal')]) | ('==' (Entity | '?principal'))] 69 | ``` 70 | 71 | ## `Action` {#grammar-action} 72 | 73 | The `Action` element consists of the `action` keyword. If specified by itself, it matches any action. Optionally, it can be followed by either the [`==`](../policies/syntax-operators.html#operator-equality) operator and an action entity, or [`in`](../policies/syntax-operators.html#operator-in) followed by an action entity or a [set](../policies/syntax-datatypes.html#datatype-set) of action entities, known as an *action group*. 74 | 75 | ``` 76 | Action ::= 'action' [( '==' Entity | 'in' ('[' EntList ']' | Entity) )] 77 | ``` 78 | 79 | ## `Resource` {#grammar-resource} 80 | 81 | The `Resource` consists of the `resource` keyword. If specified by itself, it matches any resource. Optionally, it can be followed by either the [`in`](../policies/syntax-operators.html#operator-in), [`==`](../policies/syntax-operators.html#operator-equality), or [`is`](../_policies/syntax-operators.html#operator-is) operator. 82 | An `is` operator may appear together with an `in` operators, but not an `==` operator. 83 | The `in` and `==` operators are followed by either an `Entity`, or the `?resource` placeholder when used in a policy template. 84 | 85 | ``` 86 | Resource ::= 'resource' [(['is' PATH] ['in' (Entity | '?resource')]) | ('==' (Entity | '?resource'))] 87 | ``` 88 | 89 | ## `Condition` {#grammar-condition} 90 | 91 | A `Condition` consists of either the `when` or `unless` keyword followed by a Bool expression surrounded by braces `{ }`. A `when` clause matches the request when the expression evaluates to `true`. An `unless` clause matches the request when the expression \(an [Expr](#grammar-expr) element\) evaluates to `false`. 92 | 93 | The parent [Policy](#grammar-policy) element can have zero or more `when` or `unless` clauses. 94 | 95 | ``` 96 | Condition ::= ('when' | 'unless') '{' Expr '}' 97 | ``` 98 | 99 | ## `Expr` {#grammar-expr} 100 | 101 | ``` 102 | Expr ::= Or | 'if' Expr 'then' Expr 'else' Expr 103 | ``` 104 | 105 | ## `Or` {#grammar-or} 106 | 107 | ``` 108 | Or ::= And {'||' And} 109 | ``` 110 | 111 | For more details, see [`||` \(OR\)](../policies/syntax-operators.html#operator-or). 112 | 113 | ## `And` {#grammar-and} 114 | 115 | ``` 116 | And ::= Relation {'&&' Relation} 117 | ``` 118 | 119 | For more details, see [`&&` \(AND\)](../policies/syntax-operators.html#operator-and). 120 | 121 | ## `Relation` {#grammar-relation} 122 | 123 | ``` 124 | Relation ::= Add [RELOP Add] | Add 'has' (IDENT | STR) | Add 'like' PAT | Add 'is' Path ('in' Add)? 125 | ``` 126 | 127 | ## `Add` {#grammar-add} 128 | 129 | ``` 130 | Add ::= Mult {('+' | '-') Mult} 131 | ``` 132 | 133 | ## `Mult` {#grammar-mult} 134 | 135 | ``` 136 | Mult ::= Unary { '*' Unary} 137 | ``` 138 | 139 | ## `Unary` {#grammar-unary} 140 | 141 | ``` 142 | Unary ::= ['!' | '-']x4 Member 143 | ``` 144 | 145 | ## `Member` {#grammar-member} 146 | 147 | ``` 148 | Member ::= Primary {Access} 149 | ``` 150 | 151 | ## `Annotation` {#grammar-annotation} 152 | 153 | ``` 154 | Annotation ::= '@' ANYIDENT ( '('STR')' )? 155 | ``` 156 | 157 | ## `Access` {#grammar-access} 158 | 159 | ``` 160 | Access ::= '.' IDENT ['(' [ExprList] ')'] | '[' STR ']' 161 | ``` 162 | 163 | ## `Primary` {#grammar-primary} 164 | 165 | ``` 166 | Primary ::= LITERAL 167 | | VAR 168 | | Entity 169 | | ExtFun '(' [ExprList] ')' 170 | | '(' Expr ')' 171 | | '[' [ExprList] ']' 172 | | '{' [RecInits] '}' 173 | ``` 174 | 175 | ## `Path` {#grammar-path} 176 | 177 | ``` 178 | Path ::= IDENT {'::' IDENT} 179 | ``` 180 | 181 | ## `Entity` {#grammar-entity} 182 | 183 | ``` 184 | Entity ::= Path '::' STR 185 | ``` 186 | 187 | ## `EntList` {#grammar-entlist} 188 | 189 | ``` 190 | EntList ::= Entity {',' Entity} 191 | ``` 192 | 193 | ## `ExprList` {#grammar-exprlist} 194 | 195 | ``` 196 | ExprList ::= Expr {',' Expr} 197 | ``` 198 | 199 | ## `ExtFun` {#grammar-extfun} 200 | 201 | ``` 202 | ExtFun ::= [Path '::'] IDENT 203 | ``` 204 | 205 | ## `RecInits` {#grammar-recinits} 206 | 207 | ``` 208 | RecInits ::= (IDENT | STR) ':' Expr {',' (IDENT | STR) ':' Expr} 209 | ``` 210 | 211 | ## `RELOP` {#grammar-relop} 212 | 213 | ``` 214 | RELOP ::= '<' | '<=' | '>=' | '>' | '!=' | '==' | 'in' 215 | ``` 216 | 217 | ## `ANYIDENT` {#grammar-any-ident} 218 | 219 | ``` 220 | ANYIDENT ::= ['_''a'-'z''A'-'Z']['_''a'-'z''A'-'Z''0'-'9']* 221 | ``` 222 | 223 | ## `IDENT` {#grammar-ident} 224 | 225 | ``` 226 | IDENT ::= ANYIDENT - RESERVED 227 | ``` 228 | 229 | ## `STR` {#grammar-str} 230 | 231 | ``` 232 | STR ::= Fully-escaped Unicode surrounded by '"'s 233 | ``` 234 | 235 | ## `PAT` {#grammar-pat} 236 | 237 | ``` 238 | PAT ::= STR with `\*` allowed as an escape 239 | ``` 240 | 241 | ## `LITERAL` {#grammar-literal} 242 | 243 | ``` 244 | LITERAL ::= BOOL | INT | STR 245 | ``` 246 | 247 | ## `BOOL` {#grammar-bool} 248 | 249 | ``` 250 | BOOL ::= 'true' | 'false' 251 | ``` 252 | 253 | ## `INT` {#grammar-int} 254 | 255 | ``` 256 | INT ::= '-'? ['0'-'9']+ 257 | ``` 258 | 259 | ## `RESERVED` {#grammar-reserved} 260 | 261 | ``` 262 | RESERVED ::= BOOL | 'if' | 'then' | 'else' | 'in' | 'like' | 'has' | 'is' | '__cedar' 263 | ``` 264 | 265 | ## `VAR` {#grammar-var} 266 | 267 | ``` 268 | VAR ::= 'principal' | 'action' | 'resource' | 'context' 269 | ``` 270 | -------------------------------------------------------------------------------- /docs/collections/_policies/templates.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Policy templates 4 | nav_order: 8 5 | --- 6 | 7 | # Cedar policy templates {#templates} 8 | {: .no_toc } 9 | 10 | A policy template is a policy that contains *placeholders*. The placeholders can represent the principal and the resource. Later, you can create a template-linked policy based on the policy template by specifying the exact principal and resource to use for this one policy. Template-linked policies are dynamic, meaning that the new policy stays linked to its policy template. When you change a policy statement in the policy template, any policies linked to that template automatically and immediately use the new statement for all authorization decisions made from that moment forward. 11 | 12 | You can use placeholders in a Cedar policy template for only the following two elements of a policy statement: 13 | 14 | + Principal – `?principal` 15 | + Resource – `?resource` 16 | 17 | You can use either one or both in a policy template. 18 | 19 | Placeholders can appear in ***only*** the policy scope on the right-hand side of the `==` or `in` operators. 20 | This includes `in` operators when appearing together with an `is` operator, but excludes solitary `is` operators. 21 | 22 | Then, when you create a policy based on the policy template, you must specify values for each of the placeholders. Those values are combined with the rest of the policy template to form a complete and usable template-linked policy. 23 | 24 | As an example, consider the scenario where a common action is to grant certain groups with the ability to view and comment on any photos that are not marked as `private`. You decide to associate the action with a **Share** button in your application's interface. You could create a template that looks like the following example. 25 | 26 | ```cedar 27 | permit ( 28 | principal in ?principal, 29 | action in [Action::"view", Action::"comment"], 30 | resource in ?resource 31 | ) 32 | unless { 33 | resource.tag =="private" 34 | }; 35 | ``` 36 | 37 | When a user chooses **Share**, your application instantiates that policy template into an individual template-linked policy. The template-linked policy references the policy template and specifies values for the placeholders. For example, a user chooses to share their `vacationTrip` album with their `friendsAndFamilies` group. Choosing **Share** in your application starts the creation of a template-linked policy that specifies `UserGroup::"friendsAndFamily"` as the principal and `Album::"vacationTrip"` as the resource. This template-linked policy behaves exactly as if it were written like the following static policy. 38 | 39 | ```cedar 40 | permit ( 41 | principal in UserGroup::"friendsAndFamily", 42 | action in [Action::"view", Action::"comment"], 43 | resource in Album::"vacationTrip" 44 | ) 45 | unless { 46 | resource.tag =="private" 47 | }; 48 | ``` 49 | 50 | However, the new policy isn't actually constructed as a static policy with that policy statement. Instead, the new policy is a template-linked policy that dynamically links the policy template with those two specific placeholder values. Later, you might choose to modify the policy template, such as by adding an additional condition to the `unless` clause. From that moment on the change immediately affects all authorization decision results for all template-linked policies created from the modified policy template. 51 | 52 | ## Considerations when using templates 53 | 54 | If you use the template approach, you tightly couple the policy store to the life-cycle management of your users. When you onboard a new user and assign them to a role, you must create template-linked policies for them. When that user changes roles, you must find those policies, archive them, and then create new template-linked policies. When the user leaves the organization, you must archive the policies for that user. If you delete the policies instead of archiving them, then you lose the historical record of who was permitted to do what, which might be required for forensics purposes. 55 | 56 | These challenges reinforce each other if the role is a complex set of permissions requiring multiple policies. In the simple example above, the permissions for the role can be expressed as a single policy statement. Therefore, assigning a principal requires the creation of a single template-linked policy. However, more complex roles might require several policies to express the permissions. In that case, the assignment and unassignment processes can become more burdensome, as you must create or delete multiple template-linked policies. 57 | -------------------------------------------------------------------------------- /docs/collections/_schema/human-readable-schema-grammar.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Cedar schema grammar 4 | nav_order: 2 5 | --- 6 | 7 | 8 | # Grammar specification for Cedar schemas {#schema-grammar} 9 | {: .no_toc } 10 | 11 | This topic describes the grammar specification for the Cedar schema format. For a more complete description, see [Cedar schema format](../schema/human-readable-schema.html). 12 | 13 | The grammar applies the following conventions. 14 | + Words with initial capital letters designate grammar constructs. 15 | + Words in all capital letters designate lexical tokens. 16 | 17 | When productions or tokens match those in the Cedar policy grammar, use the same names, for example `IDENT` and `Path`. 18 | 19 | Grammar constructs use the following symbols: 20 | + `|` designates alternatives. 21 | + `[]` designates optional productions. 22 | + `()` designates grouping. 23 | + `{}` designates repetition of a form zero or more times. 24 | 25 | Tokens are defined using regular expressions: 26 | + `[]` designates character ranges. 27 | + `|` designates alternation. 28 | + `*` , `+` , and `?` designate zero or more, one or more, and zero or one occurrences, respectively. 29 | + `~` designates complement. 30 | + `-` designates difference. 31 | 32 | The grammar adopts the same string escaping rules as the [Cedar policy grammar](../policies/syntax-grammar.html). 33 | 34 | ``` 35 | Annotation := '@' IDENT '(' STR ')' 36 | Annotations := {Annotations} 37 | Schema := {Namespace} 38 | Namespace := (Annotations 'namespace' Path '{' {Decl} '}') | Decl 39 | Decl := Entity | Action | TypeDecl 40 | Entity := Annotations 'entity' Idents ['in' EntOrTyps] [['='] RecType] ['tags' Type] ';' | Annotations 'entity' Idents 'enum' '[' STR+ ']' ';' 41 | Action := Annotations 'action' Names ['in' RefOrRefs] [AppliesTo]';' 42 | TypeDecl := Annotations 'type' TYPENAME '=' Type ';' 43 | Type := Path | SetType | RecType 44 | EntType := Path 45 | SetType := 'Set' '<' Type '>' 46 | RecType := '{' [AttrDecls] '}' 47 | AttrDecls := Annotations Name ['?'] ':' Type [',' | ',' AttrDecls] 48 | AppliesTo := 'appliesTo' '{' AppDecls '}' 49 | AppDecls := ('principal' | 'resource') ':' EntOrTyps [',' | ',' AppDecls] 50 | | 'context' ':' RecType [',' | ',' AppDecls] 51 | Path := IDENT {'::' IDENT} 52 | Ref := Path '::' STR | Name 53 | RefOrRefs := Ref | '[' [RefOrRefs] ']' 54 | EntTypes := Path {',' Path} 55 | EntOrTyps := EntType | '[' [EntTypes] ']' 56 | Name := IDENT | STR 57 | Names := Name {',' Name} 58 | Idents := IDENT {',' IDENT} 59 | 60 | IDENT := ['_''a'-'z''A'-'Z']['_''a'-'z''A'-'Z''0'-'9']* 61 | TYPENAME := IDENT - RESERVED 62 | STR := Fully-escaped Unicode surrounded by '"'s 63 | PRIMTYPE := 'Long' | 'String' | 'Bool' 64 | WHITESPC := Unicode whitespace 65 | COMMENT := '//' ~NEWLINE* NEWLINE 66 | RESERVED := 'Bool' | 'Boolean' | 'Entity' | 'Extension' | 'Long' | 'Record' | 'Set' | 'String' 67 | ``` 68 | -------------------------------------------------------------------------------- /docs/collections/_schema/images/AVP-BASICS.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_schema/images/AVP-BASICS.jpg -------------------------------------------------------------------------------- /docs/collections/_schema/images/Cedar 1 - black.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_schema/images/Cedar 1 - black.png -------------------------------------------------------------------------------- /docs/collections/_schema/images/Cedar 1 - white.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_schema/images/Cedar 1 - white.png -------------------------------------------------------------------------------- /docs/collections/_schema/images/Cedar 2 - black.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_schema/images/Cedar 2 - black.png -------------------------------------------------------------------------------- /docs/collections/_schema/images/Cedar 2 - green.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_schema/images/Cedar 2 - green.png -------------------------------------------------------------------------------- /docs/collections/_schema/images/Cedar 2 - white.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_schema/images/Cedar 2 - white.png -------------------------------------------------------------------------------- /docs/collections/_schema/images/Cedar1-green.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_schema/images/Cedar1-green.png -------------------------------------------------------------------------------- /docs/collections/_schema/images/PhotoFlash.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_schema/images/PhotoFlash.png -------------------------------------------------------------------------------- /docs/collections/_schema/images/entities.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_schema/images/entities.png -------------------------------------------------------------------------------- /docs/collections/_schema/images/hierarchy.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_schema/images/hierarchy.png -------------------------------------------------------------------------------- /docs/collections/_schema/images/quotas-transitive-parents.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_schema/images/quotas-transitive-parents.png -------------------------------------------------------------------------------- /docs/collections/_schema/images/resource-lives-in-container.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_schema/images/resource-lives-in-container.png -------------------------------------------------------------------------------- /docs/collections/_schema/images/security-of-cedar.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_schema/images/security-of-cedar.png -------------------------------------------------------------------------------- /docs/collections/_schema/images/separate-principals-from-resources-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_schema/images/separate-principals-from-resources-2.png -------------------------------------------------------------------------------- /docs/collections/_schema/images/separate-principals-from-resources-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_schema/images/separate-principals-from-resources-3.png -------------------------------------------------------------------------------- /docs/collections/_schema/images/separate-principals-from-resources.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_schema/images/separate-principals-from-resources.png -------------------------------------------------------------------------------- /docs/collections/_schema/images/source/entities.drawio: -------------------------------------------------------------------------------- 1 | 7VrbctowEP0aPybjO+kjlyTNQ2fSYTqlfckIW7GVyJYri1u/vitbxhcMgYQESHlCeyStdlfnCNmgWf1ofstREn5jPqaaqftzzRpopml0dAc+JLLIkY6tgIATXw0qgSH5ixWoK3RCfJzWBgrGqCBJHfRYHGNP1DDEOZvVhz0yWl81QQFeAYYeoqvoT+KLMEevHL3Ev2IShMXKhq56IlQMVkAaIp/NKpB1rVl9zpjIW9G8j6ksXlGXfN7Nmt5lYBzHYpsJXnLXZc73CN+F9kOfGaOn0e8L5WWK6EQlrJkuihLN6sXjVH6IRQI93R8p5tBFYaneWLYC2WoOxnKxriYjcf9MZGa9JxTj0mp1kSE+mTahNEHxupWQ57GJTFyu1i0NaW9eGirUcFzAtRCyLROLggccFvCxLKUO3bOQCDxMkCd7Z8B8wEIRUbAMGRwlQQxtih9LZ1PMBZ6v3TxjSQnQEmYRFnwBQ5RszCvFollJQsNWWFghoKswpHgfLF2V1ICGYscOTDHbmFLZpkqxiopnVbpI8zLJfYoZjxCtbUnr5tY5V+t6YRclr94YyTvl1CKNMRvX5h0i0Yzz+8xzG2E2Ez8BAVruoQVoHUyAn0ZwQAtv+2+Ek5bY+lSPWGS2fWiR2WeRvVVkTyyM/w+Nrc30iCXmmIeWmPPxEruFoiefSmPwZPPwiCJCF6cvNTaL4QTMpmRn4bZPcceoMjXBLN4CHM3t0T2rbk+q4wTHfnqW3RHKzm7I7vD3yc5ZdvuRncdmjD9jfhbeMQqv+X13+Fum0fZmu1E07Ad4qEzGRcgCFiN6XaLVosGh35W/J4A5psx7lhAdZ7YsHfFg60EQAnFRjItZjPOZN4QWflLB2TPuM8p4FoXl2E7PtaGnvod4TsSoWBvavyR+6ShrMK8MGywKI4bSjapGZZY0y2mZVczLKyPLsXn/oXpswj28oe6qylCGAIuXngJW+VTlS8EpjikSZFqPrY0wyt09IxD1kptGnZqu3qBcnpKaVP39pOnnJUd5ziuOMvouU3wDo9vewJ8Z/e6MtrZktPtxjHYa15zXUrqpjRVH703pttdtJ0Xpgp4X+qXeMXbjaGbdY06gjPIasCNxj4iQlt143P3ySkJanQYhO9sREjYTLSrDEjkg3RBwpz3gXeMq9ZBHsF91tL0pOyl1vOLA3+PBbZ/ggdy8Rzv7OpDBLP9qkg8v/7BjXf8D -------------------------------------------------------------------------------- /docs/collections/_schema/images/structure-of-policy.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_schema/images/structure-of-policy.png -------------------------------------------------------------------------------- /docs/collections/_schema/images/transitive-attributes-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_schema/images/transitive-attributes-2.png -------------------------------------------------------------------------------- /docs/collections/_schema/images/transitive-attributes-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_schema/images/transitive-attributes-3.png -------------------------------------------------------------------------------- /docs/collections/_schema/images/transitive-attributes.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/collections/_schema/images/transitive-attributes.png -------------------------------------------------------------------------------- /docs/collections/_schema/json-schema-grammar.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: JSON schema grammar 4 | nav_order: 2 5 | --- 6 | 7 | 8 | # Grammar specification for JSON schemas {#schema-grammar} 9 | {: .no_toc } 10 | 11 | This topic describes the grammar specification for the Cedar schema. For a more complete description, see [Schema format](../schema/schema.html). 12 | 13 | This grammar uses the following symbols: 14 | 15 | + A vertical bar `|` designates alternatives. Only one alternative can be used. 16 | + Brackets `[ ]` designate an optional element. 17 | + Parentheses `( )` designate grouping 18 | + Braces `{ }` designate repetition of an element zero or more times. 19 | 20 | Capitalized words represent grammar constructs, and lexical tokens are displayed in all-caps. 21 | 22 | Tokens are defined using regular expressions: 23 | 24 | + Brackets `[ ]` represent a range of characters. 25 | + A vertical bar `|` designates alternatives. 26 | + An asterisk `*` represents zero or more occurrences of an element. 27 | + A plus sign `+` represents one or more occurrences of an element. 28 | + A question mark `?` represents exactly zero or one occurrences of an element. 29 | + A tilde `~` represents the complement of the following element. 30 | + A hyphen `-` represents difference. 31 | + Single quotation marks `' '` surround elements that must be entered literally as shown. 32 | 33 | The grammar ignores whitespace and comments. 34 | 35 | ## `Schema` {#grammar-schema} 36 | 37 | A schema consists of a [`Namespace`](#grammar-schema-Namespace) JSON object that contains [`EntityTypes`](#grammar-schema-EntityTypes), [`Actions`](#grammar-schema-Actions), and (optional) [`CommonTypes`](#grammar-schema-CommonTypes) components. 38 | The grammar assumes a particular order of keys in JSON objects to simplify the presentation, but this order is not technically required. 39 | For example, the grammar as written requires that entity type declarations appear before actions, but actions may nonetheless be declared before entity types. 40 | 41 | ``` 42 | Schema ::= '{' Namespace ':' '{' EntityTypes ',' Actions [',' CommonTypes] '}' '}' 43 | ``` 44 | 45 | ## `Namespace` {#grammar-schema-Namespace} 46 | 47 | The `Namespace` element is a string made up of a sequence of one or more substrings separated by double colons (`::`). This namespace serves as a qualifier, or disambiguator, for entity types that might be defined in multiple namespaces. The type reference must include the namespace so that Cedar uses the correct entity type. For more information see [`namespace`](../schema/schema.html#schema-namepace). 48 | 49 | ``` 50 | Namespace ::= '"' STR { '::' STR } '"' 51 | ``` 52 | 53 | ## `EntityTypes` {#grammar-schema-EntityTypes} 54 | 55 | The `EntityTypes` element is identified by the keyword `entityTypes` followed by a comma-separated list of Entity types supported by your application. For more information see [`entityTypes`](../schema/schema.html#schema-entityTypes). 56 | 57 | ``` 58 | EntityTypes ::= 'entityTypes' ':' '{' [ EntityType { ',' EntityType } ] '}' 59 | ``` 60 | 61 | ## `EntityType` {#grammar-schema-EntityType} 62 | 63 | An `EntityType` element describes one entity type supported by your application. It begins with a name string for the entity type that, when qualified by its parent [namespace](#grammar-schema-Namespace), uniquely identifies this entity type. This element contains a `memberOfTypes` element that is an array list of any parent entity types that entities of this type can be a member or child of in a hierarchy. It also contains a `shape` element that describes the attributes of entities of this type, and a `tags` element that declares the tag type for entities of this type. 64 | 65 | ``` 66 | EntityType ::= IDENT ':' '{' [ 'memberOfTypes' ':' '[' [ IDENT { ',' IDENT } ] ']' ] [ ',' 'shape': TypeJson ] [ ',' 'tags': Type ] '}' | IDENT ':' '{' 'enum': STR+ '}' 67 | ``` 68 | 69 | ## `Actions` {#grammar-schema-Actions} 70 | 71 | The `Actions` element is a list of the individual actions supported by your application. 72 | 73 | ``` 74 | Actions ::= '"actions"' ':' '{' [ Action { ',' Action } ] '}' 75 | ``` 76 | 77 | ## `Action` {#grammar-schema-Action} 78 | 79 | The `Action` element describes one action supported by your application. An action consists of a name string, an optional `memberOf` element, and a required `appliesTo` element. 80 | The `memberOf` element specifies what action groups the declared action is a member of in the action hierarchy. 81 | The `appliesTo` element defines the principal types, resource types, and other context information that can be specified in a request for the action. 82 | 83 | ``` 84 | Action ::= STR ':' '{' [ '"memberOf"' ':' '[' [ STR { ',' STR } ] ']' ] ',' '"appliesTo"' ':' '{' PrincipalTypes ',' ResourceTypes [',' Context] '}' '}' 85 | ``` 86 | 87 | ## `PrincipalTypes` {#grammar-schema-PrincipalTypes} 88 | 89 | The `PrincipalTypes` element is identified by the keyword `principalType` followed by a comma-separated array list of the principal types supported by your application for the containing action. 90 | 91 | ``` 92 | PrincipalTypes ::= '"principalTypes"': '[' [ IDENT { ',' IDENT } ] ']' 93 | ``` 94 | 95 | ## `ResourceTypes` {#grammar-schema-ResourceTypes} 96 | 97 | The `ResourceTypes` element follows the same format and serves the same purpose as as the `PrincipalTypes`, but instead lists the resource types supported for the containing action. 98 | 99 | ``` 100 | ResourceTypes ::= '"resourceTypes"': '[' [ IDENT { ',' IDENT } ] ']' 101 | ``` 102 | 103 | ## `Context` {#grammar-schema-Context} 104 | 105 | The `Context` element describes the type of the context record for an action using the same `TypeJson` format used for the shape of an entity type. 106 | 107 | ``` 108 | Context ::= '"context"' ':' TypeJson 109 | ``` 110 | 111 | ## `TypeJson` {#grammar-schema-TypeJson} 112 | 113 | The `TypeJson` element describes 114 | 115 | ``` 116 | TypeJson ::= '{' Type '}' 117 | ``` 118 | 119 | ## `Type` {#grammar-schema-Type} 120 | 121 | The `Type` element describes 122 | 123 | ``` 124 | Type ::= Primitive | Set | EntityRef | Record | Extension | EntityOrCommon 125 | ``` 126 | 127 | ## `Primitive` {#grammar-schema-Primitive} 128 | 129 | The `Primitive` element describes 130 | 131 | ``` 132 | Primitive ::= '"type":' ('"Long"' | '"String"' | '"Boolean"' | TYPENAME) 133 | ``` 134 | 135 | ## `Set` {#grammar-schema-Set} 136 | 137 | The `Set` element describes 138 | 139 | ``` 140 | Set ::= '"type": "Set", "element": ' TypeJson 141 | ``` 142 | 143 | ## `EntityRef` {#grammar-schema-EntityRef} 144 | 145 | The `EntityRef` element describes 146 | 147 | ``` 148 | EntityRef ::= '"type": "Entity", "name": "' Name '"' 149 | ``` 150 | 151 | ## `Record` {#grammar-schema-Record} 152 | 153 | The `Record` element describes 154 | 155 | ``` 156 | Record ::= '"type": "Record", "attributes": {' [ RecordAttr { ',' RecordAttr } ] '}' 157 | ``` 158 | 159 | ## `RecordAttr` {#grammar-schema-RecordAttr} 160 | 161 | The `RecordAttr` element describes 162 | 163 | ``` 164 | RecordAttr ::= STR ': {' Type [',' '"required"' ':' ( true | false )] '}' 165 | ``` 166 | 167 | ## `Extension` {#grammar-schema-Extension} 168 | 169 | The `Extension` element describes 170 | 171 | ``` 172 | Extension ::= '"type": "Extension", "name": "' Name '"' 173 | ``` 174 | 175 | ## `EntityOrCommon` {#grammar-schema-EntityOrCommon} 176 | 177 | The `EntityOrCommon` element describes 178 | 179 | ``` 180 | EntityOrCommon ::= '"type": "EntityOrCommon", "name": "' Name '"' 181 | ``` 182 | 183 | ## `STR` {#grammar-schema-STR} 184 | 185 | ``` 186 | STR ::= Fully-escaped Unicode surrounded by '"'s 187 | ``` 188 | 189 | ## `IDENT` {#grammar-IDENT} 190 | 191 | ``` 192 | IDENT ::= ['_''a'-'z''A'-'Z']['_''a'-'z''A'-'Z''0'-'9']* - RESERVED 193 | ``` 194 | 195 | ## `CommonTypes` {#grammar-schema-CommonTypes} 196 | 197 | The `CommonTypes` element is identified by the keyword `commonTypes` followed by a comma-separated list of common types supported by your application. For more information see [`commonTypes`](../schema/schema.html#schema-commonTypes). 198 | 199 | ``` 200 | CommonTypes ::= 'commonTypes' ':' '{' [ CommonType { ',' CommonType } ] '}' 201 | ``` 202 | 203 | ## `CommonType` {#grammar-schema-CommonType} 204 | 205 | A `CommonType` element describes one common type supported by your application. It begins with a name string for the common type that, when qualified by its parent [namespace](#grammar-schema-Namespace), uniquely identifies this common type. 206 | 207 | ``` 208 | CommonType ::= TYPENAME ':' TypeJson 209 | TYPENAME ::= IDENT - RESERVED 210 | RESERVED ::= 'Bool' | 'Boolean' | 'Entity' | 'Extension' | 'Long' | 'Record' | 'Set' | 'String' 211 | ``` 212 | -------------------------------------------------------------------------------- /docs/doc-history.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: forward 3 | target: other/doc-history.html 4 | --- 5 | 6 | 7 | -------------------------------------------------------------------------------- /docs/entities-syntax.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: forward 3 | target: auth/entities-syntax.html 4 | --- 5 | 6 | 7 | -------------------------------------------------------------------------------- /docs/fonts/amazonember_w_rg.woff2: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/fonts/amazonember_w_rg.woff2 -------------------------------------------------------------------------------- /docs/fonts/vaultalarm-regular.otf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/fonts/vaultalarm-regular.otf -------------------------------------------------------------------------------- /docs/fonts/vaultalarm-sharp.otf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/fonts/vaultalarm-sharp.otf -------------------------------------------------------------------------------- /docs/images/AVP-BASICS.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/images/AVP-BASICS.jpg -------------------------------------------------------------------------------- /docs/images/Cedar 1 - black.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/images/Cedar 1 - black.png -------------------------------------------------------------------------------- /docs/images/Cedar 1 - white.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/images/Cedar 1 - white.png -------------------------------------------------------------------------------- /docs/images/Cedar 2 - black.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/images/Cedar 2 - black.png -------------------------------------------------------------------------------- /docs/images/Cedar 2 - green.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/images/Cedar 2 - green.png -------------------------------------------------------------------------------- /docs/images/Cedar 2 - white.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/images/Cedar 2 - white.png -------------------------------------------------------------------------------- /docs/images/Cedar1-green.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/images/Cedar1-green.png -------------------------------------------------------------------------------- /docs/images/PhotoFlash.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/images/PhotoFlash.png -------------------------------------------------------------------------------- /docs/images/entities.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/images/entities.png -------------------------------------------------------------------------------- /docs/images/favicon.ico: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/images/favicon.ico -------------------------------------------------------------------------------- /docs/images/hierarchy.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/images/hierarchy.png -------------------------------------------------------------------------------- /docs/images/quotas-transitive-parents.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/images/quotas-transitive-parents.png -------------------------------------------------------------------------------- /docs/images/resource-lives-in-container.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/images/resource-lives-in-container.png -------------------------------------------------------------------------------- /docs/images/security-of-cedar.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/images/security-of-cedar.png -------------------------------------------------------------------------------- /docs/images/separate-principals-from-resources-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/images/separate-principals-from-resources-2.png -------------------------------------------------------------------------------- /docs/images/separate-principals-from-resources-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/images/separate-principals-from-resources-3.png -------------------------------------------------------------------------------- /docs/images/separate-principals-from-resources.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/images/separate-principals-from-resources.png -------------------------------------------------------------------------------- /docs/images/source/entities.drawio: -------------------------------------------------------------------------------- 1 | 7VrbctowEP0aPybjO+kjlyTNQ2fSYTqlfckIW7GVyJYri1u/vitbxhcMgYQESHlCeyStdlfnCNmgWf1ofstREn5jPqaaqftzzRpopml0dAc+JLLIkY6tgIATXw0qgSH5ixWoK3RCfJzWBgrGqCBJHfRYHGNP1DDEOZvVhz0yWl81QQFeAYYeoqvoT+KLMEevHL3Ev2IShMXKhq56IlQMVkAaIp/NKpB1rVl9zpjIW9G8j6ksXlGXfN7Nmt5lYBzHYpsJXnLXZc73CN+F9kOfGaOn0e8L5WWK6EQlrJkuihLN6sXjVH6IRQI93R8p5tBFYaneWLYC2WoOxnKxriYjcf9MZGa9JxTj0mp1kSE+mTahNEHxupWQ57GJTFyu1i0NaW9eGirUcFzAtRCyLROLggccFvCxLKUO3bOQCDxMkCd7Z8B8wEIRUbAMGRwlQQxtih9LZ1PMBZ6v3TxjSQnQEmYRFnwBQ5RszCvFollJQsNWWFghoKswpHgfLF2V1ICGYscOTDHbmFLZpkqxiopnVbpI8zLJfYoZjxCtbUnr5tY5V+t6YRclr94YyTvl1CKNMRvX5h0i0Yzz+8xzG2E2Ez8BAVruoQVoHUyAn0ZwQAtv+2+Ek5bY+lSPWGS2fWiR2WeRvVVkTyyM/w+Nrc30iCXmmIeWmPPxEruFoiefSmPwZPPwiCJCF6cvNTaL4QTMpmRn4bZPcceoMjXBLN4CHM3t0T2rbk+q4wTHfnqW3RHKzm7I7vD3yc5ZdvuRncdmjD9jfhbeMQqv+X13+Fum0fZmu1E07Ad4qEzGRcgCFiN6XaLVosGh35W/J4A5psx7lhAdZ7YsHfFg60EQAnFRjItZjPOZN4QWflLB2TPuM8p4FoXl2E7PtaGnvod4TsSoWBvavyR+6ShrMK8MGywKI4bSjapGZZY0y2mZVczLKyPLsXn/oXpswj28oe6qylCGAIuXngJW+VTlS8EpjikSZFqPrY0wyt09IxD1kptGnZqu3qBcnpKaVP39pOnnJUd5ziuOMvouU3wDo9vewJ8Z/e6MtrZktPtxjHYa15zXUrqpjRVH703pttdtJ0Xpgp4X+qXeMXbjaGbdY06gjPIasCNxj4iQlt143P3ySkJanQYhO9sREjYTLSrDEjkg3RBwpz3gXeMq9ZBHsF91tL0pOyl1vOLA3+PBbZ/ggdy8Rzv7OpDBLP9qkg8v/7BjXf8D -------------------------------------------------------------------------------- /docs/images/structure-of-policy.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/images/structure-of-policy.png -------------------------------------------------------------------------------- /docs/images/transitive-attributes-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/images/transitive-attributes-2.png -------------------------------------------------------------------------------- /docs/images/transitive-attributes-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/images/transitive-attributes-3.png -------------------------------------------------------------------------------- /docs/images/transitive-attributes.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cedar-policy/cedar-docs/67ad2993497c45f9d7ca9a7584362946fa546b4b/docs/images/transitive-attributes.png -------------------------------------------------------------------------------- /docs/js/awsdocs.css: -------------------------------------------------------------------------------- 1 | .hljs { 2 | background-color: #f9f9f9; 3 | color: #16191f 4 | } 5 | 6 | .hljs b, 7 | .hljs strong { 8 | color: #16191f 9 | } 10 | 11 | .hljs-comment, 12 | .hljs-quote { 13 | color: #687078; 14 | font-style: italic 15 | } 16 | 17 | .hljs-deletion, 18 | .hljs-doctag, 19 | .hljs-formula, 20 | .hljs-keyword, 21 | .hljs-name, 22 | .hljs-section, 23 | .hljs-selector-tag, 24 | .hljs-subst { 25 | color: #794938; 26 | } 27 | 28 | .hljs-literal { 29 | color: #0184bb 30 | } 31 | 32 | .hljs-addition, 33 | .hljs-attribute, 34 | .hljs-meta-string, 35 | .hljs-regexp, 36 | .hljs-string { 37 | color: #0b6125 38 | } 39 | 40 | .hljs-built_in, 41 | .hljs-class .hljs-title { 42 | color: #c18401 43 | } 44 | 45 | .hljs-attr, 46 | .hljs-attribute, 47 | .hljs-number, 48 | .hljs-selector-attr, 49 | .hljs-selector-class, 50 | .hljs-selector-pseudo, 51 | .hljs-template-variable, 52 | .hljs-type, 53 | .hljs-variable { 54 | color: #986801 55 | } 56 | 57 | .hljs-bullet, 58 | .hljs-link, 59 | .hljs-meta, 60 | .hljs-selector-id, 61 | .hljs-symbol, 62 | .hljs-title { 63 | color: #4078f2 64 | } 65 | 66 | .hljs-emphasis { 67 | font-style: italic 68 | } 69 | 70 | .hljs-strong { 71 | font-weight: 700 72 | } 73 | 74 | .hljs-link { 75 | text-decoration: underline 76 | } 77 | 78 | .hljs a, 79 | .hljs a span { 80 | color: #0073bb 81 | } 82 | 83 | .hljs code.replaceable, 84 | .hljs code.replaceable span { 85 | color: #d13212 86 | } 87 | 88 | pre.programlisting, 89 | pre.screen { 90 | background-color: #f9f9f9; 91 | border: 1px solid var(--color-border-divider-default-k96bks, #eaeded); 92 | border-radius: 3px; 93 | overflow: auto; 94 | position: relative 95 | } 96 | 97 | code.hljs { 98 | display: block; 99 | font-family: Monaco, Menlo, Consolas, Courier Prime, Courier, Courier New, monospace; 100 | padding: 16px 50px 16px 16px 101 | } 102 | 103 | code.userinput { 104 | color: #1d8102 105 | } -------------------------------------------------------------------------------- /docs/js/github.min.css: -------------------------------------------------------------------------------- 1 | /*! 2 | Theme: GitHub 3 | Description: Light theme as seen on github.com 4 | Updated: 2024-04-21 5 | 6 | Derived from https://github.com/highlightjs/highlight.js/blob/main/src/styles/github.css 7 | Current colors taken from GitHub's CSS --color-prettylights-syntax-* variables 8 | */pre code.hljs{display:block;overflow-x:auto;padding:1em}code.hljs{padding:3px 5px}.hljs{--color-prettylights-syntax-comment: #57606a;--color-prettylights-syntax-constant: #0550ae;--color-prettylights-syntax-constant-other-reference-link: #0a3069;--color-prettylights-syntax-entity: #6639ba;--color-prettylights-syntax-storage-modifier-import: #24292f;--color-prettylights-syntax-entity-tag: #0550ae;--color-prettylights-syntax-keyword: #cf222e;--color-prettylights-syntax-string: #0a3069;--color-prettylights-syntax-variable: #953800;--color-prettylights-syntax-brackethighlighter-unmatched: #82071e;--color-prettylights-syntax-brackethighlighter-angle: #57606a;--color-prettylights-syntax-invalid-illegal-text: #f6f8fa;--color-prettylights-syntax-invalid-illegal-bg: #82071e;--color-prettylights-syntax-carriage-return-text: #f6f8fa;--color-prettylights-syntax-carriage-return-bg: #cf222e;--color-prettylights-syntax-string-regexp: #116329;--color-prettylights-syntax-markup-list: #3b2300;--color-prettylights-syntax-markup-heading: #0550ae;--color-prettylights-syntax-markup-italic: #24292f;--color-prettylights-syntax-markup-bold: #24292f;--color-prettylights-syntax-markup-deleted-text: #82071e;--color-prettylights-syntax-markup-deleted-bg: #ffebe9;--color-prettylights-syntax-markup-inserted-text: #116329;--color-prettylights-syntax-markup-inserted-bg: #dafbe1;--color-prettylights-syntax-markup-changed-text: #953800;--color-prettylights-syntax-markup-changed-bg: #ffd8b5;--color-prettylights-syntax-markup-ignored-text: #eaeef2;--color-prettylights-syntax-markup-ignored-bg: #0550ae;--color-prettylights-syntax-meta-diff-range: #8250df;--color-prettylights-syntax-sublimelinter-gutter-mark: #8c959f;color:#24292f;background:#fff}.hljs-doctag,.hljs-keyword,.hljs-meta .hljs-keyword,.hljs-template-tag,.hljs-template-variable,.hljs-type,.hljs-variable.language_{color:var(--color-prettylights-syntax-keyword)}.hljs-title,.hljs-title.class_,.hljs-title.class_.inherited__,.hljs-title.function_{color:var(--color-prettylights-syntax-entity)}.hljs-attr,.hljs-attribute,.hljs-literal,.hljs-meta,.hljs-number,.hljs-operator,.hljs-property,.hljs-selector-attr,.hljs-selector-class,.hljs-selector-id,.hljs-variable{color:var(--color-prettylights-syntax-constant)}.hljs-meta .hljs-string,.hljs-regexp,.hljs-string{color:var(--color-prettylights-syntax-string)}.hljs-built_in,.hljs-symbol{color:var(--color-prettylights-syntax-variable)}.hljs-code,.hljs-comment,.hljs-formula{color:var(--color-prettylights-syntax-comment)}.hljs-name,.hljs-quote,.hljs-selector-pseudo,.hljs-selector-tag{color:var(--color-prettylights-syntax-entity)}.hljs-subst{color:var(--color-prettylights-syntax-storage-modifier-import)}.hljs-section{color:var(--color-prettylights-syntax-markup-heading);font-weight:700}.hljs-bullet{color:var(--color-prettylights-syntax-markup-list)}.hljs-emphasis{color:var(--color-prettylights-syntax-markup-italic);font-style:italic}.hljs-strong{color:var(--color-prettylights-syntax-markup-bold);font-weight:700}.hljs-addition{color:var(--color-prettylights-syntax-markup-inserted-text);background-color:var(--color-prettylights-syntax-markup-inserted-bg)}.hljs-deletion{color:var(--color-prettylights-syntax-markup-deleted-text);background-color:var(--color-prettylights-syntax-markup-deleted-bg)} 9 | -------------------------------------------------------------------------------- /docs/js/hljs-cedar.min.js: -------------------------------------------------------------------------------- 1 | (()=>{function t(e){let s={match:/\b(?:ip|decimal)(?=\()/,scope:"built_in"},n={match:/\b(?=","<=",">","<","\\+","-","\\*","in","like","has","is"].join("|")+")"+/(?!\w)/.source,scope:"operator",relevance:0},p={scope:"number",begin:"0|-?[1-9](_?[0-9])*",relevance:0},E={match:/(?=\b)(([_a-zA-Z][_a-zA-Z0-9]*::)*[_a-zA-Z][_a-zA-Z0-9]*)(?=::)/,scope:"title.class"},T={match:[/is/,/\s+/,/([_a-zA-Z][_a-zA-Z0-9]*::)*[_a-zA-Z][_a-zA-Z0-9]*/],scope:{1:"operator",3:"title.class"}},b={scope:"title.function.invoke",begin:"(?=.)(contains|containsAll|containsAny|isEmpty)(?=\\()",relevance:0},_={scope:"title.function.invoke",begin:"(?=.)(lessThan|lessThanOrEqual|greaterThan|greaterThanOrEqual)(?=\\()",relevance:0},O={scope:"title.function.invoke",begin:"(?=.)(isIpv4|isIpv6|isLoopback|isMulticast|isInRange)(?=\\()",relevance:0};return{name:"Cedar",aliases:["cedar"],case_insensitive:!1,keywords:o,contains:[e.QUOTE_STRING_MODE,e.C_LINE_COMMENT_MODE,s,n,c,p,r,E,T,l,b,_,O,a]}}function i(e){let s={match:/\b(?:namespace|type|entity|action)(?=\s+)/,scope:"keyword"},n={begin:"\\b(?:in)\\b|\\b(?:appliesTo)(?=\\s*{)",scope:"keyword"},a={begin:"=",scope:"operator"},c={begin:"{|}|\\[|]|;",scope:"punctuation"},o={begin:/\b(?:[_a-zA-Z][_a-zA-Z0-9]*)(?=[?]?:(?!:))/,scope:"property"};return{name:"Cedar schema",aliases:["cedarschema"],case_insensitive:!1,contains:[e.QUOTE_STRING_MODE,e.C_LINE_COMMENT_MODE,s,n,a,c,o]}}window.hljsCedar=t;window.hljsCedarschema=i;})(); 2 | //! Copyright Cedar Contributors 3 | //! SPDX-License-Identifier: Apache-2.0 4 | -------------------------------------------------------------------------------- /docs/json-format.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: forward 3 | target: policies/json-format.html 4 | --- 5 | 6 | 7 | -------------------------------------------------------------------------------- /docs/overview/best-practices.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: forward 3 | target: \.\./bestpractices/bp-naming-conventions.html 4 | --- 5 | 6 | 7 | -------------------------------------------------------------------------------- /docs/scenario.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: forward 3 | target: overview/scenario.html 4 | --- 5 | 6 | 7 | -------------------------------------------------------------------------------- /docs/schema-grammar.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: forward 3 | target: schema/json-schema-grammar.html 4 | --- 5 | 6 | 7 | -------------------------------------------------------------------------------- /docs/schema.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: forward 3 | target: schema/schema.html 4 | --- 5 | 6 | 7 | -------------------------------------------------------------------------------- /docs/security.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: forward 3 | target: other/security.html 4 | --- 5 | 6 | 7 | -------------------------------------------------------------------------------- /docs/syntax-datatypes.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: forward 3 | target: policies/syntax-datatypes.html 4 | --- 5 | 6 | 7 | -------------------------------------------------------------------------------- /docs/syntax-entity.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: forward 3 | target: policies/syntax-entity.html 4 | --- 5 | 6 | 7 | -------------------------------------------------------------------------------- /docs/syntax-grammar.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: forward 3 | target: policies/syntax-grammar.html 4 | --- 5 | 6 | 7 | -------------------------------------------------------------------------------- /docs/syntax-operators.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: forward 3 | target: policies/syntax-operators.html 4 | --- 5 | 6 | 7 | -------------------------------------------------------------------------------- /docs/syntax-policy.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: forward 3 | target: policies/syntax-policy.html 4 | --- 5 | 6 | 7 | -------------------------------------------------------------------------------- /docs/templates.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: forward 3 | target: policies/templates.html 4 | --- 5 | 6 | 7 | -------------------------------------------------------------------------------- /docs/terminology.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: forward 3 | target: overview/terminology.html 4 | --- 5 | 6 | 7 | -------------------------------------------------------------------------------- /docs/validation.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: forward 3 | target: policies/validation.html 4 | --- 5 | 6 | 7 | --------------------------------------------------------------------------------