chore: bdd tests should not use OAuth2 authentication to auth service

Makefile

@@ -53,7 +53,7 @@ build-kms-cli-binaries:
 	@docker run -i --rm \
 		-v $(abspath .):/opt/workspace/kms \
 		--entrypoint "/opt/workspace/kms/scripts/build-cli.sh" \
-		ghcr.io/gythialy/golang-cross:latest
+		ghcr.io/gythialy/golang-cross:go-1.18
 
 .PHONY: extract-kms-cli-binaries
 extract-kms-cli-binaries:

test/bdd/features/keystore_api.feature

@@ -9,7 +9,6 @@
 Feature: Keystore management operations
 
   Scenario: User creates a keystore
-    Given Key Server is running on "localhost" port "4466"
-    And   Hub Auth is running on "auth.trustbloc.local" port "8070"
-    When  user makes an HTTP POST to "https://localhost:4466/v1/keystores" to create a keystore
+    Given Key Server is running on "localhost" port "8076"
+    When  user makes an HTTP POST to "https://localhost:8076/v1/keystores" to create a keystore
     Then  user gets a response with HTTP status "200 OK" and valid key store URL and root capabilities

test/bdd/features/kms_api.feature

@@ -8,90 +8,87 @@
 @kms
 Feature: KMS and crypto operations
   Background:
-    Given Key Server is running on "localhost" port "4466"
-      And Hub Auth is running on "auth.trustbloc.local" port "8070"
-      And "Alice" has logged into auth server
-      And "Bob" has logged into auth server
-      And "Alice" has created a profile on auth server
-      And "Bob" has created a profile on auth server
+    Given Key Server is running on "localhost" port "8076"
+      And "Alice" has configured ZCAP authentication
+      And "Bob" has configured ZCAP authentication
 
   Scenario: User creates a key
     Given "Alice" has created an empty keystore on Key Server
 
-    When  "Alice" makes an HTTP POST to "https://localhost:4466/v1/keystores/{keystoreID}/keys" to create "ED25519" key
+    When  "Alice" makes an HTTP POST to "https://localhost:8076/v1/keystores/{keystoreID}/keys" to create "ED25519" key
     Then  "Alice" gets a response with HTTP status "200 OK"
      And  "Alice" gets a response with non-empty "key_url"
 
   Scenario: User creates multiple keys with parallel requests
     Given "Alice" has created an empty keystore on Key Server
 
-    When  "Alice" makes parallel HTTP POST requests to "https://localhost:4466/v1/keystores/{keystoreID}/keys" to create "AES128GCM,ChaCha20Poly1305,XChaCha20Poly1305,ED25519,HMACSHA256Tag256,NISTP256ECDHKW,X25519ECDHKW,BLS12381G2" keys
+    When  "Alice" makes parallel HTTP POST requests to "https://localhost:8076/v1/keystores/{keystoreID}/keys" to create "AES128GCM,ChaCha20Poly1305,XChaCha20Poly1305,ED25519,HMACSHA256Tag256,NISTP256ECDHKW,X25519ECDHKW,BLS12381G2" keys
     Then  "Alice" gets a response with HTTP status "200 OK" for each request
 
   Scenario: User exports a public key
     Given "Bob" has created a keystore with "ED25519" key on Key Server
 
-    When  "Bob" makes an HTTP GET to "https://localhost:4466/v1/keystores/{keystoreID}/keys/{keyID}/export" to export public key
+    When  "Bob" makes an HTTP GET to "https://localhost:8076/v1/keystores/{keystoreID}/keys/{keyID}/export" to export public key
     Then  "Bob" gets a response with HTTP status "200 OK"
      And  "Bob" gets a response with non-empty "public_key"
 
   Scenario: User creates and exports a key
     Given "Alice" has created an empty keystore on Key Server
 
-    When  "Alice" makes an HTTP POST to "https://localhost:4466/v1/keystores/{keystoreID}/keys" to create and export "ED25519" key
+    When  "Alice" makes an HTTP POST to "https://localhost:8076/v1/keystores/{keystoreID}/keys" to create and export "ED25519" key
     Then  "Alice" gets a response with HTTP status "200 OK"
      And  "Alice" gets a response with non-empty "key_url"
      And  "Alice" gets a response with non-empty "public_key"
 
   Scenario: User imports a private key
     Given "Bob" has created an empty keystore on Key Server
 
-    When  "Bob" makes an HTTP PUT to "https://localhost:4466/v1/keystores/{keystoreID}/keys" to import a private key with ID "keyID"
+    When  "Bob" makes an HTTP PUT to "https://localhost:8076/v1/keystores/{keystoreID}/keys" to import a private key with ID "keyID"
     Then  "Bob" gets a response with HTTP status "200 OK"
      And  "Bob" gets a response with "key_url" with value "https://kms.trustbloc.local:8076/v1/keystores/([^/]+)/keys/keyID"
 
   Scenario: User signs a message and verifies a signature
     Given "Alice" has created a keystore with "ED25519" key on Key Server
 
-    When  "Alice" makes an HTTP POST to "https://localhost:4466/v1/keystores/{keystoreID}/keys/{keyID}/sign" to sign "test message"
+    When  "Alice" makes an HTTP POST to "https://localhost:8076/v1/keystores/{keystoreID}/keys/{keyID}/sign" to sign "test message"
     Then  "Alice" gets a response with HTTP status "200 OK"
      And  "Alice" gets a response with non-empty "signature"
 
-    When  "Alice" makes an HTTP POST to "https://localhost:4466/v1/keystores/{keystoreID}/keys/{keyID}/verify" to verify "signature" for "test message"
+    When  "Alice" makes an HTTP POST to "https://localhost:8076/v1/keystores/{keystoreID}/keys/{keyID}/verify" to verify "signature" for "test message"
     Then  "Alice" gets a response with HTTP status "200 OK"
      And  "Alice" gets a response with no "errMessage"
 
   Scenario: User creates and rotates a key
     Given "Alice" has created a keystore with "AES256GCM" key on Key Server
-      And "Alice" makes an HTTP POST to "https://localhost:4466/v1/keystores/{keystoreID}/keys/{keyID}/encrypt" to encrypt "test message"
+      And "Alice" makes an HTTP POST to "https://localhost:8076/v1/keystores/{keystoreID}/keys/{keyID}/encrypt" to encrypt "test message"
 
-    When  "Alice" makes an HTTP POST to "https://localhost:4466/v1/keystores/{keystoreID}/keys/{keyID}/rotate" to rotate "AES256GCM" key
+    When  "Alice" makes an HTTP POST to "https://localhost:8076/v1/keystores/{keystoreID}/keys/{keyID}/rotate" to rotate "AES256GCM" key
     Then  "Alice" gets a response with HTTP status "200 OK"
 
-    When  "Alice" makes an HTTP POST to "https://localhost:4466/v1/keystores/{keystoreID}/keys/{keyID}/decrypt" to decrypt "ciphertext"
+    When  "Alice" makes an HTTP POST to "https://localhost:8076/v1/keystores/{keystoreID}/keys/{keyID}/decrypt" to decrypt "ciphertext"
     Then  "Alice" gets a response with HTTP status "200 OK"
      And  "Alice" gets a response with "plaintext" with value "test message"
 
   Scenario: User encrypts/decrypts a message
     Given "Bob" has created a keystore with "AES256GCM" key on Key Server
 
-    When  "Bob" makes an HTTP POST to "https://localhost:4466/v1/keystores/{keystoreID}/keys/{keyID}/encrypt" to encrypt "test message"
+    When  "Bob" makes an HTTP POST to "https://localhost:8076/v1/keystores/{keystoreID}/keys/{keyID}/encrypt" to encrypt "test message"
     Then  "Bob" gets a response with HTTP status "200 OK"
      And  "Bob" gets a response with non-empty "ciphertext"
      And  "Bob" gets a response with non-empty "nonce"
 
-    When  "Bob" makes an HTTP POST to "https://localhost:4466/v1/keystores/{keystoreID}/keys/{keyID}/decrypt" to decrypt "ciphertext"
+    When  "Bob" makes an HTTP POST to "https://localhost:8076/v1/keystores/{keystoreID}/keys/{keyID}/decrypt" to decrypt "ciphertext"
     Then  "Bob" gets a response with HTTP status "200 OK"
      And  "Bob" gets a response with "plaintext" with value "test message"
 
   Scenario: User computes/verifies MAC for data
     Given "Alice" has created a keystore with "HMACSHA256Tag256" key on Key Server
 
-    When  "Alice" makes an HTTP POST to "https://localhost:4466/v1/keystores/{keystoreID}/keys/{keyID}/computemac" to compute MAC for "test data"
+    When  "Alice" makes an HTTP POST to "https://localhost:8076/v1/keystores/{keystoreID}/keys/{keyID}/computemac" to compute MAC for "test data"
     Then  "Alice" gets a response with HTTP status "200 OK"
      And  "Alice" gets a response with non-empty "mac"
 
-    When  "Alice" makes an HTTP POST to "https://localhost:4466/v1/keystores/{keystoreID}/keys/{keyID}/verifymac" to verify MAC "mac" for "test data"
+    When  "Alice" makes an HTTP POST to "https://localhost:8076/v1/keystores/{keystoreID}/keys/{keyID}/verifymac" to verify MAC "mac" for "test data"
     Then  "Alice" gets a response with HTTP status "200 OK"
      And  "Alice" gets a response with no "errMessage"
 
@@ -100,11 +97,11 @@ Feature: KMS and crypto operations
       And "Bob" has created a keystore with "NISTP256ECDHKW" key on Key Server
       And "Alice" has a public key of "Bob"
 
-    When  "Alice" makes an HTTP POST to "https://localhost:4466/v1/keystores/{keystoreID}/wrap" to wrap "testCEK" for "Bob"
+    When  "Alice" makes an HTTP POST to "https://localhost:8076/v1/keystores/{keystoreID}/wrap" to wrap "testCEK" for "Bob"
     Then  "Alice" gets a response with HTTP status "200 OK"
      And  "Alice" gets a response with non-empty "wrapped_key"
 
-    When  "Bob" makes an HTTP POST to "https://localhost:4466/v1/keystores/{keystoreID}/keys/{keyID}/unwrap" to unwrap "wrapped_key" from "Alice"
+    When  "Bob" makes an HTTP POST to "https://localhost:8076/v1/keystores/{keystoreID}/keys/{keyID}/unwrap" to unwrap "wrapped_key" from "Alice"
     Then  "Bob" gets a response with HTTP status "200 OK"
      And  "Bob" gets a response with content of "testCEK" key
 
@@ -113,10 +110,10 @@ Feature: KMS and crypto operations
       And "Bob" has created a keystore with "X25519ECDHKW" key on Key Server
       And "Alice" has a public key of "Bob"
 
-    When  "Alice" makes an HTTP POST to "https://localhost:4466/v1/keystores/{keystoreID}/wrap" to wrap "testCEK" for "Bob"
+    When  "Alice" makes an HTTP POST to "https://localhost:8076/v1/keystores/{keystoreID}/wrap" to wrap "testCEK" for "Bob"
     Then  "Alice" gets a response with HTTP status "200 OK"
      And  "Alice" gets a response with non-empty "wrapped_key"
 
-    When  "Bob" makes an HTTP POST to "https://localhost:4466/v1/keystores/{keystoreID}/keys/{keyID}/unwrap" to unwrap "wrapped_key" from "Alice"
+    When  "Bob" makes an HTTP POST to "https://localhost:8076/v1/keystores/{keystoreID}/keys/{keyID}/unwrap" to unwrap "wrapped_key" from "Alice"
     Then  "Bob" gets a response with HTTP status "200 OK"
      And  "Bob" gets a response with content of "testCEK" key

test/bdd/features/kms_crypto_box_api.feature

@@ -8,26 +8,23 @@
 @kms_crypto_box
 Feature: KMS CryptoBox operations
   Background:
-    Given Key Server is running on "localhost" port "4466"
-      And Hub Auth is running on "auth.trustbloc.local" port "8070"
-      And "Alice" has logged into auth server
-      And "Bob" has logged into auth server
-      And "Alice" has created a profile on auth server
-      And "Bob" has created a profile on auth server
+    Given Key Server is running on "localhost" port "8076"
+      And "Alice" has configured ZCAP authentication
+      And "Bob" has configured ZCAP authentication
 
   Scenario: User A anonymously encrypts (wrap as "easy") a payload for User B, User B decrypts (unwrap as "easy open") it
     Given "Alice" has created a keystore with "ED25519" key on Key Server
       And "Bob" has created a keystore with "ED25519" key on Key Server
       And "Alice" has a public key of "Bob"
       And "Bob" has a public key of "Alice"
 
-    When  "Alice" makes an HTTP POST to "https://localhost:4466/v1/keystores/{keystoreID}/keys/{keyID}/wrap" to easy "test payload" for "Bob"
+    When  "Alice" makes an HTTP POST to "https://localhost:8076/v1/keystores/{keystoreID}/keys/{keyID}/wrap" to easy "test payload" for "Bob"
     Then  "Alice" gets a response with HTTP status "200 OK"
      And  "Alice" gets a response with non-empty "ciphertext"
 
     # since easyOpen now works like unwrap, adding `keys/{keyID}` below is necessary to follow the same pattern as unwrap even if
     # easyOpen does not use keyID (it uses keys found in the POST request instead)
-    When  "Bob" makes an HTTP POST to "https://localhost:4466/v1/keystores/{keystoreID}/keys/{keyID}/unwrap" to easyOpen "ciphertext" from "Alice"
+    When  "Bob" makes an HTTP POST to "https://localhost:8076/v1/keystores/{keystoreID}/keys/{keyID}/unwrap" to easyOpen "ciphertext" from "Alice"
     Then  "Bob" gets a response with HTTP status "200 OK"
      And  "Bob" gets a response with "plaintext" with value "test payload"
 
@@ -39,6 +36,6 @@ Feature: KMS CryptoBox operations
 
     # since sealOpen now works like unwrap, adding `keys/{keyID}` below is necessary to follow the same pattern as unwrap even if
     # sealOpen does not use keyID (it uses keys found in the POST request instead)
-    When  "Alice" makes an HTTP POST to "https://localhost:4466/v1/keystores/{keystoreID}/keys/{keyID}/unwrap" to sealOpen "ciphertext" from "Bob"
+    When  "Alice" makes an HTTP POST to "https://localhost:8076/v1/keystores/{keystoreID}/keys/{keyID}/unwrap" to sealOpen "ciphertext" from "Bob"
     Then  "Alice" gets a response with HTTP status "200 OK"
      And  "Alice" gets a response with "plaintext" with value "test payload"

test/bdd/fixtures/docker-compose.yml

@@ -167,27 +167,6 @@ services:
     networks:
       - bdd_net
 
-
-  oathkeeper-ops-keyserver.trustbloc.local:
-    container_name: oathkeeper-ops-keyserver.trustbloc.local
-    image: oryd/oathkeeper:v0.38.4-alpine
-    ports:
-      - 4466:4466
-    command: /bin/sh -c "cp /etc/tls/ec-cacert.pem /usr/local/share/ca-certificates/;update-ca-certificates;oathkeeper serve proxy --config /oathkeeper/config.yaml"
-    user: root
-    entrypoint: ""
-    environment:
-      - LOG_LEVEL=debug
-      - PORT=4466
-      - ISSUER_URL=https://oathkeeper-proxy.trustbloc.local
-      - SERVE_PROXY_TLS_KEY_PATH=/etc/tls/ec-key.pem
-      - SERVE_PROXY_TLS_CERT_PATH=/etc/tls/ec-pubCert.pem
-    volumes:
-      - ./oathkeeper-config/ops-keyserver:/oathkeeper
-      - ./keys/tls:/etc/tls
-    networks:
-      - bdd_net
-
   auth.trustbloc.local:
     container_name: auth.trustbloc.local
     image: ${AUTH_REST_IMAGE}:${AUTH_REST_IMAGE_TAG}