Recipes: Add authz (#637)

Co-authored-by: Sean Park-Ross <[email protected]>

docs/auth/authentication/jwt/index.mdx

@@ -36,4 +36,4 @@ to determine access to your data.
 ## Next steps
 
 - Learn how to [enable JWT authentication](auth/authentication/jwt/setup.mdx) with Hasura DDN
-- Learn how to [set up admin-level and public requests](auth/authentication/jwt/special-roles.mdx)
+- Learn how to [set up admin-level and public requests](/recipes/authorization/index.mdx)

docs/auth/authentication/webhook/index.mdx

@@ -35,4 +35,4 @@ any other information as session variables in the response body.
 ## Next steps
 
 - Learn how to [enable webhook authentication](auth/authentication/webhook/setup.mdx) with Hasura DDN
-- Learn how to [set up admin-level and public requests](auth/authentication/webhook/special-roles.mdx)
+- Learn how to [set up admin-level and public requests](/recipes/authorization/index.mdx)

docs/recipes/authorization/1-simple-user-permissions.mdx

@@ -0,0 +1,148 @@
+---
+sidebar_position: 2
+sidebar_label: Limit data to users
+description: "Learn how to return only data belonging to a user."
+keywords:
+  - hasura
+  - hasura ddn
+  - authorization
+  - user access
+  - recipe
+  - guide
+seoFrontMatterUpdated: false
+---
+
+# Limit Data to Users
+
+## Introduction
+
+In this recipe, you'll learn how to configure [permissions](/supergraph-modeling/permissions.mdx) to limit users to
+accessing only their data.
+
+This can be done by passing a value in the header of each request to your supergraph; Hasura will then use that value to
+return only the data which matches conditions you specify.
+
+:::info Prerequisites
+
+Before continuing, ensure you have:
+
+- A local Hasura DDN project.
+- Either JWT or Webhook mode enabled in your [AuthConfig](/supergraph-modeling/auth-config.mdx).
+
+:::
+
+## Recipe
+
+### Step 1. Create your ModelPermissions {#step-one}
+
+To create a new role, such as `user`, simply add the role to the list of `permissions` for the model to which you wish
+to limit access. Then, set up your access control rules.
+
+In the example below, we'll allow users with the role of `user` to access only their own rows from a `Users` model by
+checking for a header value matching their `id`:
+
+```yaml title="For example, in a Users.hml"
+---
+kind: ModelPermissions
+version: v1
+definition:
+  modelName: Users
+  permissions:
+    - role: admin
+      select:
+        filter: null
+        #highlight-start
+    - role: user
+      select:
+        filter:
+          fieldComparison:
+            field: id
+            operator: _eq
+            value:
+              sessionVariable: x-hasura-user-id
+        #highlight-end
+```
+
+You can modify this to meet your own data modeling by ensuring that the `field` is a column or type that can be compared
+to the value of the session variable you send in the header of your request. In this example, we're using
+`x-hasura-user-id`, but you can use any `x-hasura-` value you wish.
+
+:::info Authentication recipes
+
+We have recipes for popular authentication providers available [here](/recipes/authentication/index.mdx)!
+
+:::
+
+### Step 2. Create your TypePermissions
+
+By adding ModelPermissions, we've made the model available to the new role. However, this role is not yet able to access
+any of the fields from the model. We can do that by adding the new role to the list of `permissions` and including which
+fields are accessible to it.
+
+```yaml title="For example, in a Users.hml"
+---
+kind: TypePermissions
+version: v1
+definition:
+  typeName: Users
+  permissions:
+    - role: admin
+      output:
+        allowedFields:
+          - createdAt
+          - email
+          - favoriteArtist
+          - id
+          - isEmailVerified
+          - lastSeen
+          - name
+          - password
+          - updatedAt
+    #highlight-start
+    - role: user
+      output:
+        allowedFields:
+          - createdAt
+          - email
+          - favoriteArtist
+          - id
+          - isEmailVerified
+          - lastSeen
+          - name
+          - password
+          - updatedAt
+    #highlight-end
+```
+
+If you want to restrict which fields the new role can access, simply omit them from the list of `allowedFields`.
+
+### Step 3. Test your permissions
+
+Create a new build of your supergraph:
+
+```sh
+ddn supergraph build local
+```
+
+Then, in a request, pass a header with the [session variable](#step-one) you identified earlier according to your
+authentication configuration. You should see a schema limited to whatever ModelPermissions you defined for your new role
+and — when executing a query — only see data meeting the filtering rule you included in the first step.
+
+## Wrapping up
+
+In this guide, you learned how to limit a user to see only their own data from a single type. However, you can use this
+same recipe and apply it to a variety of scenarios.
+
+As you continue building out your supergraph, keep in mind that authentication and authorization are crucial components.
+Always validate your configuration and regularly test your setup to ensure it functions as expected across different
+roles and environments.
+
+## Learn more about authorization and authentication
+
+- [Authorization](/auth/authorization/index.mdx) with Hasura DDN
+- [Permissions](/supergraph-modeling/permissions.mdx) with Hasura DDN
+- [Authentication](/auth/authentication/index.mdx) with Hasura DDN
+
+## Similar recipes
+
+- [Authorization recipes](/recipes/authorization/index.mdx)