@toa.io/extensions.exposition 0.24.0-alpha.9 → 1.0.0-alpha.10

package/features/dynamic.feature

@@ -11,6 +11,7 @@ Feature: Dynamic tree updates
       """yaml
       exposition:
         /:
+          io:output: true
           isolated: true
           GET: enumerate
       """
@@ -27,6 +28,7 @@ Feature: Dynamic tree updates
       """yaml
       exposition:
         /:
+          io:output: true
           GET: enumerate
       """
     When the following request is received:
@@ -44,19 +46,22 @@ Feature: Dynamic tree updates
       """yaml
       exposition:
         /:id:
+          io:output: true
           GET: observe
       """
     Then the `pots` is stopped
     Then the `pots` is running with the following manifest:
       """yaml
       exposition:
-        /:id:
-          GET: observe
-        /big:
-          GET:
-            endpoint: enumerate
-            query:
-              criteria: volume>200
+        /:
+          io:output: true
+          /:id:
+            GET: observe
+          /big:
+            GET:
+              endpoint: enumerate
+              query:
+                criteria: volume>200
       """
     When the following request is received:
       """
@@ -73,6 +78,7 @@ Feature: Dynamic tree updates
       """yaml
       exposition:
         /big:
+          io:output: true
           GET:
             endpoint: enumerate
             query:
@@ -83,6 +89,7 @@ Feature: Dynamic tree updates
       """yaml
       exposition:
         /big:
+          io:output: true
           GET:
             endpoint: enumerate
             query:

package/features/errors.feature

@@ -46,7 +46,7 @@ Feature: Errors
       accept: application/yaml
       """
     Then the following reply is sent:
-      """http
+      """
       405 Method Not Allowed
       """
 
@@ -57,7 +57,7 @@ Feature: Errors
       accept: application/yaml
       """
     Then the following reply is sent:
-      """http
+      """
       501 Not Implemented
       """
 
@@ -66,7 +66,7 @@ Feature: Errors
       """yaml
       exposition:
         /:
-          POST: transit
+          POST: create
       """
     When the following request is received:
       """
@@ -197,6 +197,7 @@ Feature: Errors
       """yaml
       /:
         GET:
+          io:output: true
           anonymous: true
           dev:stub: hello
       """

package/features/etag.feature

@@ -0,0 +1,97 @@
+Feature: Optimistic concurrency control
+
+  Scenario: Using `etag`
+    Given the `pots` is running with the following manifest:
+      """yaml
+      exposition:
+        /:
+          io:output: true
+          POST: create
+          /:id:
+            GET: observe
+            PUT: transit
+      """
+    When the following request is received:
+      """
+      POST /pots/ HTTP/1.1
+      accept: application/yaml
+      content-type: application/yaml
+
+      title: Hello
+      volume: 1.5
+      """
+    Then the following reply is sent:
+      """
+      201 Created
+      etag: "1"
+
+      id: ${{ id }}
+      """
+    When the following request is received:
+      """
+      GET /pots/${{ id }}/ HTTP/1.1
+      """
+    Then the following reply is sent:
+      """
+      200 OK
+      etag: "1"
+      """
+    When the following request is received:
+      """
+      GET /pots/${{ id }}/ HTTP/1.1
+      if-none-match: "1"
+      """
+    Then the following reply is sent:
+      """
+      304 Not Modified
+      etag: "1"
+      """
+    When the following request is received:
+      """
+      PUT /pots/${{ id }}/ HTTP/1.1
+      content-type: application/yaml
+      if-match: "38"
+
+      volume: 2.5
+      """
+    Then the following reply is sent:
+      """
+      412 Precondition Failed
+      """
+    When the following request is received:
+      """
+      PUT /pots/${{ id }}/ HTTP/1.1
+      content-type: application/yaml
+      if-match: "1"
+
+      volume: 2.5
+      """
+    Then the following reply is sent:
+      """
+      200 OK
+      etag: "2"
+      """
+
+  Scenario: Unexpected `if-match` format
+    Given the `pots` is running with the following manifest:
+      """yaml
+      exposition:
+        /:
+          /:id:
+            PUT: transit
+      """
+    When the following request is received:
+      """
+      PUT /pots/fa177da8393544139915795816ad6b97/ HTTP/1.1
+      accept: text/plain
+      content-type: application/yaml
+      if-match: "oopsie"
+
+      volume: 2.5
+      """
+    Then the following reply is sent:
+      """
+      400 Bad Request
+
+      Invalid ETag.
+      """

package/features/identity.basic.feature

@@ -16,12 +16,28 @@ Feature: Basic authentication
       """
       201 Created
       """
+    When the following request is received:
+      """
+      POST /identity/basic/ HTTP/1.1
+      content-type: application/yaml
+      accept: application/yaml
+
+      username: developer
+      password: secret#1234
+      """
+    Then the following reply is sent:
+      """
+      409 Conflict
+
+      - username
+      """
 
   Scenario: Creating new Identity using inception
     Given the `users` is running with the following manifest:
       """yaml
       exposition:
         /:
+          io:output: true
           anonymous: true     # checking compatibility with anonymous access
           POST:
             incept: id
@@ -67,11 +83,42 @@ Feature: Basic authentication
       """
       200 OK
       """
+    # username is taken
+    When the following request is received:
+      """
+      POST /users/ HTTP/1.1
+      authorization: Basic dXNlcjphbm90aGVycGFzczEyMzQ=
+      accept: application/yaml
+      content-type: application/yaml
+
+      name: Bill Smith
+      """
+    Then the following reply is sent:
+      """
+      409 Conflict
+
+      - username
+      """
+    # credentials already exists
+    When the following request is received:
+      """
+      POST /users/ HTTP/1.1
+      authorization: Basic dXNlcjpwYXNzMTIzNA==
+      accept: application/yaml
+      content-type: application/yaml
+
+      name: Bill Smith
+      """
+    Then the following reply is sent:
+      """
+      403 Forbidden
+      """
 
   Scenario: Changing the password
     Given the annotation:
       """yaml
       /:
+        io:output: true
         /:id:
           id: id
           GET:
@@ -115,6 +162,25 @@ Feature: Basic authentication
       200 OK
       """
 
+  Scenario: Changing other identity the password
+    Given the `identity.basic` database contains:
+      | _id                              | username  | password                                                     | _version |
+      | efe3a65ebbee47ed95a73edd911ea328 | developer | $2b$10$ZRSKkgZoGnrcTNA5w5eCcu3pxDzdTduhteVYXcp56AaNcilNkwJ.O | 1        |
+      | 6c0be50cbfb043acafe69cc7d3895f84 | attacker  | $2b$10$ZRSKkgZoGnrcTNA5w5eCcu3pxDzdTduhteVYXcp56AaNcilNkwJ.O | 1        |
+    When the following request is received:
+      """
+      PATCH /identity/basic/efe3a65ebbee47ed95a73edd911ea328/ HTTP/1.1
+      authorization: Basic YXR0YWNrZXI6c2VjcmV0
+      accept: application/yaml
+      content-type: application/yaml
+
+      password: new-secret
+      """
+    Then the following reply is sent:
+      """
+      403 Forbidden
+      """
+
   Scenario Outline: <problem> not meeting the requirements
     When the following request is received:
       """
@@ -173,6 +239,7 @@ Feature: Basic authentication
     And the annotation:
       """yaml
       /:
+        io:output: true
         GET:
           auth:role: system:stub
           dev:stub:
@@ -244,6 +311,7 @@ Feature: Basic authentication
       """yaml
       exposition:
         /:
+          io:output: true
           anonymous: true
           POST:
             incept: id

package/features/identity.feature

@@ -17,7 +17,7 @@ Feature: Identity resource
     Then the following reply is sent:
       """
       200 OK
-      authorization: Token ${{ token }}
+      authorization: Token ${{ User.token }}
 
       id: efe3a65ebbee47ed95a73edd911ea328
       roles:
@@ -27,14 +27,30 @@ Feature: Identity resource
     When the following request is received:
       """
       GET /identity/ HTTP/1.1
-      authorization: Token ${{ token }}
+      authorization: Token ${{ User.token }}
       accept: application/yaml
       """
     Then the following reply is sent:
       """
       200 OK
 
-      id: efe3a65ebbee47ed95a73edd911ea328
+      id: ${{ User.id }}
+      roles:
+        - developer
+        - system:identity
+      """
+    # checking that it returns the same id for given token
+    When the following request is received:
+      """
+      GET /identity/ HTTP/1.1
+      authorization: Token ${{ User.token }}
+      accept: application/yaml
+      """
+    Then the following reply is sent:
+      """
+      200 OK
+
+      id: ${{ User.id }}
       roles:
         - developer
         - system:identity

package/features/identity.federation.feature

@@ -0,0 +1,153 @@
+Feature: Identity Federation
+
+  Background:
+    Given the `identity.federation` database is empty
+    Given local IDP is running
+
+  Scenario: Getting identity for a new user
+    Given the `identity.federation` configuration:
+      """yaml
+      explicit_identity_creation: false
+      trust:
+        - issuer: http://localhost:44444
+      """
+    And the IDP token for User is issued
+    When the following request is received:
+      """
+      GET /identity/ HTTP/1.1
+      authorization: Bearer ${{ User.id_token }}
+      accept: application/yaml
+      content-type: application/yaml
+      """
+    Then the following reply is sent:
+      """
+      200 OK
+      authorization: Token ${{ User.token }}
+
+      id: ${{ User.id }}
+      roles: []
+      """
+    # validate TOKEN
+    When the following request is received:
+      """
+      GET /identity/ HTTP/1.1
+      accept: application/yaml
+      authorization: Token ${{ User.token }}
+      """
+    Then the following reply is sent:
+      """
+      200 OK
+      id: ${{ User.id }}
+      """
+    # ensuring identity idempotency
+    When the following request is received:
+      """
+      GET /identity/ HTTP/1.1
+      authorization: Bearer ${{ User.id_token }}
+      accept: application/yaml
+      """
+    Then the following reply is sent:
+      """
+      200 OK
+      id: ${{ User.id }}
+      """
+
+  Scenario: Getting identity for a user with symmetric tokens
+    Given the `identity.federation` configuration:
+      """yaml
+      explicit_identity_creation: false
+      trust:
+        - issuer: http://localhost:44444
+          secrets:
+            HS384:
+              k1: the-secret
+      """
+    And the IDP HS384 token for GoodUser is issued with following secret:
+      """
+      the-secret
+      """
+    When the following request is received:
+      """
+      GET /identity/ HTTP/1.1
+      authorization: Bearer ${{ GoodUser.id_token }}
+      accept: application/yaml
+      content-type: application/yaml
+      """
+    Then the following reply is sent:
+      """
+      200 OK
+      authorization: Token ${{ GoodUser.token }}
+
+      id: ${{ GoodUser.id }}
+      """
+
+  Scenario: Creating an Identity using inception with existing credentials
+    Given the `identity.federation` configuration:
+      """yaml
+      trust:
+        - issuer: http://localhost:44444
+      """
+    Given the `users` is running with the following manifest:
+      """yaml
+      exposition:
+        /:
+          anonymous: true
+          POST:
+            io:output: true
+            incept: id
+            endpoint: create
+      """
+    And the IDP token for Bill is issued
+    When the following request is received:
+      # identity inception
+      """
+      POST /users/ HTTP/1.1
+      authorization: Bearer ${{ Bill.id_token }}
+      accept: application/yaml
+      content-type: application/yaml
+
+      name: Bill Smith
+      """
+    Then the following reply is sent:
+      """
+      201 Created
+      authorization: Token ${{ Bill.token }}
+
+      id: ${{ Bill.id }}
+      """
+    # check that both tokens corresponds to the same id
+    When the following request is received:
+      """
+      GET /identity/ HTTP/1.1
+      authorization: Token ${{ Bill.token }}
+      accept: application/yaml
+      """
+    Then the following reply is sent:
+      """
+      200 OK
+      id: ${{ Bill.id }}
+      """
+    When the following request is received:
+      """
+      GET /identity/ HTTP/1.1
+      authorization: Bearer ${{ Bill.id_token }}
+      accept: application/yaml
+      """
+    Then the following reply is sent:
+      """
+      200 OK
+      id: ${{ Bill.id }}
+      """
+    And the following request is received:
+      # same credentials
+      """
+      POST /users/ HTTP/1.1
+      authorization: Bearer ${{ Bill.id_token }}
+      content-type: text/plain
+
+      name: Mary Louis
+      """
+    Then the following reply is sent:
+      """
+      403 Forbidden
+      """

package/features/identity.roles.feature

@@ -1,6 +1,8 @@
 Feature: Roles management
 
   Scenario: Adding a role to an Identity
+    # root:secret
+    # user:pass
     Given the `identity.basic` database contains:
       | _id                              | username | password                                                     |
       | 72cf9b0ab0ac4ab2b8036e4e940ddcae | root     | $2b$10$Qq/qnyyU5wjrbDXyWok14OnqAZv/z.pLhz.UddatjI6eHU/rFof4i |
@@ -11,6 +13,7 @@ Feature: Roles management
     And the annotation:
       """yaml
       /:
+        io:output: true
         auth:role: test
         GET:
           dev:stub:
@@ -49,3 +52,151 @@ Feature: Roles management
       """
       200 OK
       """
+
+  Scenario Outline: Delegating roles
+    # moderator:secret
+    # assistant:pass
+    Given the `identity.basic` database contains:
+      | _id                              | username  | password                                                     |
+      | 72cf9b0ab0ac4ab2b8036e4e940ddcae | moderator | $2b$10$Qq/qnyyU5wjrbDXyWok14OnqAZv/z.pLhz.UddatjI6eHU/rFof4i |
+      | 4344518184ad44228baffce7a44fd0b1 | assistant | $2b$10$JoiAQUS7tzobDAFIDBWhWeEIJv933dQetyjRzSmfQGaJE5ZlJbmYy |
+    And the `identity.roles` database contains:
+      | _id                              | identity                         | role                             |
+      | 9c4702490ff84f2a9e1b1da2ab64bdd4 | 72cf9b0ab0ac4ab2b8036e4e940ddcae | system:identity:roles:delegation |
+      | 30c969e05ff6437097ed5f07fc52358e | 72cf9b0ab0ac4ab2b8036e4e940ddcae | app:moderation                   |
+    And the annotation:
+      """yaml
+      /:
+        io:output: true
+        auth:role: app:moderation:photos
+        GET:
+          dev:stub:
+            access: granted!
+      """
+    When the following request is received:
+      # assistant doesn't have the required role
+      """
+      GET / HTTP/1.1
+      authorization: Basic YXNzaXN0YW50OnBhc3M=
+      """
+    Then the following reply is sent:
+      """
+      403 Forbidden
+      """
+    When the following request is received:
+      # moderator delegates a role to an assistant
+      """
+      POST /identity/roles/4344518184ad44228baffce7a44fd0b1/ HTTP/1.1
+      authorization: Basic bW9kZXJhdG9yOnNlY3JldA==
+      content-type: application/yaml
+
+      role: <role>
+      """
+    Then the following reply is sent:
+      """
+      201 Created
+      """
+    When the following request is received:
+      # assistant has access
+      """
+      GET / HTTP/1.1
+      authorization: Basic YXNzaXN0YW50OnBhc3M=
+      """
+    Then the following reply is sent:
+      """
+      200 OK
+      """
+    Examples:
+      | role                  |
+      | app:moderation        |
+      | app:moderation:photos |
+
+  Scenario: Delegating role out of own scope
+    Given the `identity.basic` database contains:
+      | _id                              | username  | password                                                     |
+      | 72cf9b0ab0ac4ab2b8036e4e940ddcae | moderator | $2b$10$Qq/qnyyU5wjrbDXyWok14OnqAZv/z.pLhz.UddatjI6eHU/rFof4i |
+      | 4344518184ad44228baffce7a44fd0b1 | assistant | $2b$10$JoiAQUS7tzobDAFIDBWhWeEIJv933dQetyjRzSmfQGaJE5ZlJbmYy |
+    And the `identity.roles` database contains:
+      | _id                              | identity                         | role                             |
+      | 9c4702490ff84f2a9e1b1da2ab64bdd4 | 72cf9b0ab0ac4ab2b8036e4e940ddcae | system:identity:roles:delegation |
+      | 30c969e05ff6437097ed5f07fc52358e | 72cf9b0ab0ac4ab2b8036e4e940ddcae | app:moderation                   |
+    And the annotation:
+      """yaml
+      /:
+        io:output: true
+        auth:role: app:moderation:photos
+        GET:
+          dev:stub:
+            access: granted!
+      """
+    When the following request is received:
+      """
+      POST /identity/roles/4344518184ad44228baffce7a44fd0b1/ HTTP/1.1
+      accept: application/yaml
+      content-type: application/yaml
+      authorization: Basic bW9kZXJhdG9yOnNlY3JldA==
+
+      role: app:finance
+      """
+    Then the following reply is sent:
+      """
+      409 Conflict
+
+      code: OUT_OF_SCOPE
+      """
+
+  Scenario: Delegating role without `system:identity:roles:delegation` role
+    Given the `identity.basic` database contains:
+      | _id                              | username  | password                                                     |
+      | 72cf9b0ab0ac4ab2b8036e4e940ddcae | moderator | $2b$10$Qq/qnyyU5wjrbDXyWok14OnqAZv/z.pLhz.UddatjI6eHU/rFof4i |
+      | 4344518184ad44228baffce7a44fd0b1 | assistant | $2b$10$JoiAQUS7tzobDAFIDBWhWeEIJv933dQetyjRzSmfQGaJE5ZlJbmYy |
+    And the `identity.roles` database contains:
+      | _id                              | identity                         | role           |
+      | 30c969e05ff6437097ed5f07fc52358e | 72cf9b0ab0ac4ab2b8036e4e940ddcae | app:moderation |
+    And the annotation:
+      """yaml
+      /:
+        io:output: true
+        auth:role: app:moderation:photos
+        GET:
+          dev:stub:
+            access: granted!
+      """
+    When the following request is received:
+      """
+      POST /identity/roles/4344518184ad44228baffce7a44fd0b1/ HTTP/1.1
+      content-type: application/yaml
+      authorization: Basic bW9kZXJhdG9yOnNlY3JldA==
+
+      role: app:moderation
+      """
+    Then the following reply is sent:
+      """
+      403 Forbidden
+      """
+
+  Scenario Outline: Invalid role name
+    Given the `identity.basic` database contains:
+      | _id                              | username | password                                                     |
+      | 72cf9b0ab0ac4ab2b8036e4e940ddcae | root     | $2b$10$Qq/qnyyU5wjrbDXyWok14OnqAZv/z.pLhz.UddatjI6eHU/rFof4i |
+    And the `identity.roles` database contains:
+      | _id                              | identity                         | role                  |
+      | 9c4702490ff84f2a9e1b1da2ab64bdd4 | 72cf9b0ab0ac4ab2b8036e4e940ddcae | system:identity:roles |
+    When the following request is received:
+      # root adds a role to a user
+      """
+      POST /identity/roles/4344518184ad44228baffce7a44fd0b1/ HTTP/1.1
+      authorization: Basic cm9vdDpzZWNyZXQ=
+      content-type: application/yaml
+
+      role: <role>
+      """
+    Then the following reply is sent:
+      """
+      400 Bad Request
+      """
+    Examples:
+      | role          |
+      | app!          |
+      | app:          |
+      | app:no spaces |

package/features/identity.tokens.feature

@@ -7,6 +7,7 @@ Feature: Tokens lifecycle
     Given the annotation:
       """yaml
       /:
+        io:output: true
         /hello/:id:
           auth:id: id
           GET:
@@ -35,6 +36,7 @@ Feature: Tokens lifecycle
     And the annotation:
       """yaml
       /:
+        io:output: true
         /hello/:id:
           auth:id: id
           GET:
@@ -72,6 +74,7 @@ Feature: Tokens lifecycle
     Given the annotation:
       """yaml
       /:
+        io:output: true
         /:id:
           id: id
           GET: