Update use-row-level-security.mdx

Add paragraph to explain how to use Row Level Security with PostgREST tool

Author: fpagny

serverless/sql-databases/how-to/use-row-level-security.mdx

@@ -84,3 +84,69 @@ This requires setting up different [IAM permissions sets](/identity-and-access-m
     <Message type="tip">
     Note that row level security and policies can be created or deleted by a table owner. In this example, you can check table owner with the following command `select * from pg_tables where tablename = 'pets';`.
     </Message>
+
+## Use Row Level Security with PostgREST
+
+PostgREST built-in Row Level Security based on users JWT relies either on [role impersonation](https://docs.postgrest.org/en/v12/references/auth.html#user-impersonation) or [transaction-scoped settings](https://docs.postgrest.org/en/v12/references/transactions.html#tx-settings). Due to connection pooling, Serverless SQL Database currently only support transaction-scoped settings and requires using a single PostgreSQL role for all queries (the internal `role_readwrite` in PostgreSQL).
+
+1. [Install PostgREST](https://docs.postgrest.org/en/v12/tutorials/tut0.html#step-1-install-postgresql)
+
+2. Create a `tutorial.conf` file with the following content:
+    ```
+    db-uri = "postgres://[user-or-application-id]:[api-secret-key]@[database-hostname]:5432/[database-name]?sslmode=require"
+    db-schemas = "[your database schema]"
+    jwt-secret = "[your jwt secret]"
+    ```
+    where:
+    - `db-uri` should use credentials with an application having **ServerlessSQLDatabaseDataReadWrite** permissions (and not **ServerlessSQLDatabaseDataReadWrite** neither **ServerlessSQLDatabaseFullAccess**)
+    - `db-schemas` is your database schema. You can use `"public"` as a default value. 
+    - `jwt-secret` can be generated using the command `openssl rand -base64 32`
+
+3. Run PostgREST:
+    ```bash
+    postgrest tutorial.conf 
+    ```
+    You can check that your are able to query your database by [generating a JWT](https://docs.postgrest.org/en/v12/tutorials/tut1.html#step-3-sign-a-token) with the payload data `{"role": "role_readwrite"}`:
+    ```bash
+     curl http://localhost:3000/pets \
+        -H "Authorization: Bearer $TOKEN"
+    ```
+    where `$TOKEN` is your generated JWT.
+    A pet list should display.
+
+4. Connect to your Serverless SQL Database with **ServerlessSQLDatabaseFullAccess** permissions, and delete the existing policy on the `pets` table:
+    ```sql
+    DROP POLICY pets_keeper ON pets;
+    ```
+
+5. Create a new policy on the `pets` table:
+    ```sql
+    CREATE POLICY pets_keeper ON pets TO role_readwrite 
+    USING (keeper = current_setting('request.jwt.claims', true)::json->>'user_type');
+    ```
+    This policy will use `current_settings` instead on `current_user` and thus check for additional fields contained by the JWT instead of only the `"role"` field.
+
+6. Generate a JWT with the following payload data:
+    ```json
+    {
+        "role": "role_readwrite",
+        "user_type": "role_readwrite"
+    }
+    ```
+    <Message type="tip">
+    In this configuration, `user_type` value from JWT will be checked against `keeper` column value in your database to authorize access. You can replace `"user_type": "role_readwrite"` by any alternative field name or value depending on your use case. However you need to keep `"role": "role_readwrite"` for any kind of users you want to authenticate through PostgREST, because alternative roles (such as `role_admin`) will already have too much privileges and be able to see any data.
+    </Message>
+
+7. Query your database using this JWT through PostgREST:
+    ```bash
+     curl http://localhost:3000/pets \
+        -H "Authorization: Bearer $TOKEN"
+    ```
+    You should only see pets with a `keeper` column value of `role_readwrite`.
+
+    Your new application can now only access a specific subset of rows based on its permissions using transaction-scoped settings.
+
+    <Message type="tip">
+    You can change your JWT payload data with `"user_type": "role_admin"` and see that only another set of rows will be displayed. You can go further by adding any additional fields or values to filter, and edit your policy to filter on a more complex set of rules.
+    </Message>
+