diff --git a/doc/testing/testplan/helper/visibility_control/README.md b/doc/testing/testplan/helper/visibility_control/README.md index 1341df4328adacf887ff9d9040fb27a9d0b20cda..7b5bf75db1dcb5c2d2fbe6d77dea85643fd61815 100644 --- a/doc/testing/testplan/helper/visibility_control/README.md +++ b/doc/testing/testplan/helper/visibility_control/README.md @@ -219,3 +219,134 @@ This test verifies the direct resource addressing logic and the error reporting. * **Step 2**: **200 OK** (Returns the specific rule object). * **Step 4**: **404 Not Found** (Ensures the resource no longer exists in the registry). +## Test Case 9: Discover Published service APIs by Unauthorised API Invoker Visibility Control + +**Test ID**: `visibility_control-9` + +**Description**: +This test case verifies that an **Invoker** cannot discover a published API if a visibility control rule explicitly restricts it. It tests the basic integration between the discovery service and the visibility control logic. + +**Pre-Conditions**: + +* The **CAPIF** services are deployed and reachable. +* A **Provider** has been registered and onboarded at **CCF**. +* A service API is published by the provider. +* An **Invoker** is registered and onboarded at **CCF**. +* Superadmin credentials (`SUPERADMIN_USERNAME`) are provisioned. + +**Execution Steps**: + +1. Authenticate as **Invoker** and send a **GET** request to the Discovery API to ensure the published API is initially visible. +2. Authenticate as **Superadmin**. +3. Send a **POST** request to `{apiRoot}/helper/visibility-control/rules` to create a rule that hides the API for this specific **API Invoker**. +4. Authenticate as **Invoker** and send a **GET** request to the Discovery API again. +5. **Superadmin** sends a **DELETE** request for the created `ruleId`. +6. **Superadmin** sends a **GET** request to the rules list to verify it is empty. + +**Expected Result**: + +* **Initial Discovery**: **200 OK** (The API is discovered). +* **Rule Creation**: **201 Created**. +* **Second Discovery**: **404 Not Found**. The response body must contain a `ProblemDetails` object with the `detail` specifying **"API Invoker {invoker_id} has no visible APIs after applying visibility rules"**. +* **Rule Deletion**: **204 No Content**. +* **Final List**: **200 OK** (List length is **0**). + +--- + +## Test Case 10: Discover Published service APIs by Unauthorised API Invoker Visibility Control (two APIs) + +**Test ID**: `visibility_control-10` + +**Description**: +This test case validates the discovery process when a **Provider** has published multiple APIs. It verifies that applying an explicit visibility rule to **deny** access to one specific API correctly hides only that targeted API from the **Invoker**, while any other published APIs remain unaffected and fully discoverable. + +**Pre-Conditions**: + +* The **CAPIF** services are deployed and reachable. +* A **Provider** is registered and onboarded at **CCF**. +* **Two** distinct service APIs are published by the same provider. +* An **Invoker** is registered and onboarded at **CCF**. +* Superadmin credentials (`SUPERADMIN_USERNAME`) are provisioned. + +**Execution Steps**: + +1. Authenticate as **Invoker** and send a **GET** request to the Discovery API to ensure both APIs are initially visible. +2. Authenticate as **Superadmin**. +3. Send a **POST** request to `{apiRoot}/helper/visibility-control/rules` creating a rule that targets only **one** of the published APIs for the invoker. +4. Authenticate as **API Invoker** and send a **GET** request to the Discovery API again. +5. **Superadmin** sends a **DELETE** request for the created `ruleId`. + +**Expected Result**: + +* **First Discovery**: **200 OK** (List length of the discovery APIs `serviceAPIDescriptions` is **2**). +* **Rule Creation**: **201 Created**. +* **Second Discovery**: **200 OK**. The `serviceAPIDescriptions` list length must be **1**, containing the targeted API and explicitly not containing the denied API. +* **Rule Deletion**: **204 No Content**. + +--- + +## Test Case 11: Discover Published service APIs by Unauthorised API Invoker Visibility Control (having several rules) + +**Test ID**: `visibility_control-11` + +**Description**: +This test validates the conflict resolution logic when multiple sequential rules apply to the same API and Invoker. Specifically, it verifies that if an initial rule denies discovery, a subsequently created rule allowing access, the system will always enforce the most recently created or updated rule. + +**Pre-Conditions**: + +* The **CAPIF** services are deployed and reachable. +* A **Provider** is registered and onboarded at **CCF**. +* **Two** distinct service APIs are published by the same provider. +* An **Invoker** is registered and onboarded at **CCF**. +* Superadmin credentials (`SUPERADMIN_USERNAME`) are provisioned. + +**Execution Steps**: + +1. Authenticate as **Invoker** and send a **GET** request to the Discovery API to ensure the API is visible. +2. Authenticate as **Superadmin** and create a first visibility rule (blocking discovery) for the **API Invoker**. +3. **API Invoker** sends a **GET** request to the Discovery API. +4. **Superadmin** creates a second visibility rule (allowing discovery) for the same **Invoker** and API. +5. **API Invoker** sends a **GET** request to the Discovery API again. + +**Expected Result**: + +* **Initial Discovery**: **200 OK**. +* **First Rule Creation**: **201 Created**. +* **Second Discovery (Blocked)**: **404 Not Found** with `detail` specifying **"API Invoker {invoker_id} has no visible APIs after applying visibility rules"**. +* **Second Rule Creation**: **201 Created**. +* **Third Discovery (Allowed)**: **200 OK** (List length is **1**, containing the published API). + +--- + +## Test Case 12: Discover Published service APIs by Unauthorised API Invoker Visibility Control (update the rule and see changes in the discovery process) + +**Test ID**: `visibility_control-12` + +**Description**: +This test validates the dynamic application of rule modifications. It ensures that updating a rule's `enabled` state via a **PATCH** request immediately affects the discovery process for API Invokers. + +**Pre-Conditions**: + +* The **CAPIF** services are deployed and reachable. +* A **Provider** is registered and onboarded at **CCF**. +* **Two** distinct service APIs are published by the same provider. +* An **Invoker** is registered and onboarded at **CCF**. +* Superadmin credentials (`SUPERADMIN_USERNAME`) are provisioned. + +**Execution Steps**: + +1. Authenticate as **Invoker** and send a **GET** request to the Discovery API to ensure the API is visible. +2. Authenticate as **Superadmin** and create a rule that hides the API. +3. **API Invoker** sends a **GET** request to the Discovery API. +4. **Superadmin** sends a **PATCH** request to `{apiRoot}/helper/visibility-control/rules/{ruleId}` changing the `enabled` field to **False**. +5. **API Invoker** sends a **GET** request to the Discovery API again. +6. **Superadmin** sends a **DELETE** request for the `ruleId`. + +**Expected Result**: + +* **Initial Discovery**: **200 OK**. +* **Rule Creation**: **201 Created**. +* **Discovery (Rule Enabled)**: **404 Not Found** with `detail` specifying **"API Invoker {invoker_id} has no visible APIs after applying visibility rules"**. +* **Rule Update (PATCH)**: **200 OK**. +* **Discovery (Rule Disabled)**: **200 OK** (The API is discoverable again, list length is **1**). +* **Rule Deletion**: **204 No Content**. \ No newline at end of file