Merge remote-tracking branch 'origin/main' into jwt-claim-pagination

Author: ddebrunner

dbquery/pagination/README.md

@@ -40,3 +40,27 @@ To retrieve the first page of a result, the operation is called with `after` omi
 Subsequent pages can then be retrieved by setting `after` to the value of `endCursor` from `pageInfo` from the previous request. `first` should be set to the value used in the first request.
 
 This is continued until `hasNextPage` is `false`.
+
+## Try it out!
+
+Deploy the schema from `dbquery/pagination` relative to the repository's root directory:
+
+```
+stepzen deploy
+```
+
+Run the [sample operations](operations.graphql):
+
+Fetch the first five records:
+
+```
+stepzen request -f operations.graphql --operation-name=Customers --var first=5
+```
+
+Fetch the next five, the value of `after` is taken from the `endCursor` field of the previous request:
+
+```
+stepzen request -f operations.graphql --operation-name=Customers --var first=5 --var after="eyJjIjoiTDpRdWVyeTpjdXN0b21lcnMiLCJvIjo0fQ=="
+```
+
+

dbquery/pagination/requests.graphql renamed to dbquery/pagination/operations.graphql

@@ -1,5 +1,5 @@
 # Page through customers from a database connection based pagination
-query CustomersConnectionBased($first: Int!, $after: String = "") {    
+query Customers($first: Int!, $after: String = "") {    
   customers(first: $first, after: $after) {
     edges {
       node {

dbquery/pagination/tests/Test.js

@@ -8,7 +8,7 @@ const {
 
 testDescription = getTestDescription("snippets", __dirname);
 
-const requestsFile = path.join(path.dirname(__dirname), "requests.graphql");
+const requestsFile = path.join(path.dirname(__dirname), "operations.graphql");
 const requests = fs.readFileSync(requestsFile, "utf8").toString();
 
 describe(testDescription, function () {
@@ -18,7 +18,7 @@ describe(testDescription, function () {
     {
       label: "first set of results",
       query: requests,
-      operationName: "CustomersConnectionBased",
+      operationName: "Customers",
       variables: { 
         first: 2 
       },
@@ -49,7 +49,7 @@ describe(testDescription, function () {
     {
       label: "next set of results",
       query: requests,
-      operationName: "CustomersConnectionBased",
+      operationName: "Customers",
       variables: {
         first: 2,
         after: CURSOR

protection/jwt-claims/README.md

@@ -0,0 +1,66 @@
+# Pulling field arguments from JWT claims
+
+This snippet shows how JWT claims can be used for field arguments.
+
+This examples demonstrates a number of StepZen capabilities:
+
+- Authorization using JWT
+- Field access rules
+- Field visibility patterns
+- `@value` directive with access to JWT claims
+  - https://www.ibm.com/docs/en/api-connect/ace/saas?topic=directives-directive-value
+- Reshaping
+
+## Restricting access through JWT claims.
+
+This example shows how a JWT claim may be used as a field argument, in this case the JWT subject claim
+is used as a customer's identifier. Thus the customer can only view their own information even though
+the backend database includes all customers.
+
+The field `Query.customer` provides an identifier lookup to all customers. This field is restricted
+from being executed by field visibility and access rules.
+
+Instead a field `Query.me` is exposed with no field arguments that invokes `Query.customer`
+with the customer identifier pulled from the `sub` claim in the request's JWT.
+
+This is implemented using `@sequence` with the first step an intermediate field (`Query._myid`) that is annotated with `@value` using ECMAScript.
+This script has access to field arguments of its annotated field (in this case none) and JWT claims through `$jwt`.
+Thus it returns the `sub` claim which is then automatically mapped as a scalar value to the sole argument of
+the next step in the sequence (`Query.customer(id:)`).
+
+An alternate version of `Query._myid` exists `Query._my_id_jsonata` showing that scripts can be implemented in JSONata.
+The default language is ECMAScript.
+
+Note these concepts could be combined with field access through ABAC rules (see `protection/simpleABACSample`)
+so that `Query.customer` could be exposed, but only customer service reps could call it
+with any customer identifier.
+
+## Try it out!
+
+Deploy the schema from `protection/jwt-claims` relative to the repository's root directory:
+
+```
+stepzen deploy
+```
+
+Run the [sample operations](operations.graphql):
+
+JWT with `sub: 5`.
+
+JWT: https://jwt.io/#debugger-io?token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiI1In0.LE_mbGsS2FbxF41r4wOYKhWdBoYhnIk0-6d6U7ibF-A
+
+Secret Key: development-only
+
+```
+stepzen request -f operations.graphql --operation-name=Customer --header "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiI1In0.LE_mbGsS2FbxF41r4wOYKhWdBoYhnIk0-6d6U7ibF-A"
+```
+
+JWT with `sub: 9`.
+
+JWT: https://jwt.io/#debugger-io?token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiI1In0.LE_mbGsS2FbxF41r4wOYKhWdBoYhnIk0-6d6U7ibF-A
+
+Secret Key: development-only
+
+```
+stepzen request -f operations.graphql --operation-name=Customer --header "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiI5In0.liX79YjQ1EIqdVSLqvKoVJxoj63OkBANwZLsZcdLzDM"
+```

protection/jwt-claims/api.graphql

@@ -0,0 +1,34 @@
+type Customer {
+  id: ID!
+  name: String
+  email: String
+}
+
+type Query {
+  """
+  Fetch customer by identifier.
+  """
+  customer(id: ID!): Customer
+    @dbquery(
+      type: "postgresql"
+      table: "customer"
+      schema: "public"
+      configuration: "postgresql_config"
+    )
+
+  """
+  Fetch my customer information.
+  Customer identifier is pulled from the JWT subject claim.
+  """
+  me: Customer @sequence(steps: [{ query: "_myid" }, { query: "customer" }])
+
+  """
+  Extract the customer's identifier from a claim in a JWT.
+  """
+  _myid: ID! @value(script: { src: "$jwt.sub" })
+
+  """
+  Extract the customer's identifier from a claim in a JWT using JSONATA.
+  """
+  _myid_jsonata: ID! @value(script: { src: "`$jwt`.sub", language: JSONATA })
+}

protection/jwt-claims/config.yaml

@@ -0,0 +1,21 @@
+deployment:
+  identity:
+    keys:
+      - algorithm: HS256
+        key: development-only
+access:
+  policies:
+    - type: Query
+      policyDefault:
+        condition: false
+      rules:
+        - name: "jwt-control"
+          fields: [me]
+          condition: "?$jwt"
+        - name: "introspection"
+          fields: [__schema, __type]
+          condition: true
+configurationset:
+  - configuration:
+      name: postgresql_config
+      uri: postgresql://postgresql.introspection.stepzen.net/introspection?user=testUserIntrospection&password=HurricaneStartingSample1934

protection/jwt-claims/index.graphql

@@ -0,0 +1,14 @@
+schema
+  @sdl(
+    files: ["api.graphql"]
+    # visibilty controls how fields included through files in this directive
+    # are visible outside the scope of this directive to GraphQL introspection
+    # and field references through @materializer etc.
+    #
+    # types and fields are regular expressions that match type and field names.
+    # Like field access rules if aat least one visibility pattern is present then by default
+    # root operation type (Query, Mutation, Subscription) fields are not exposed.
+    visibility: [{ expose: true, types: "Query", fields: "me" }]
+  ) {
+  query: Query
+}

protection/jwt-claims/operations.graphql

@@ -0,0 +1,6 @@
+query Customer {
+  me {
+    id
+    name
+  }
+}

protection/jwt-claims/stepzen.config.json

@@ -0,0 +1,3 @@
+{
+  "endpoint": "api/miscellaneous"
+}