Skip to content

Test Plan for Visibility Control Feature

At this documentation you will have all information and related files and examples of test plan for this feature.

Feature Description

The Visibility Control API is a helper service within OpenCAPIF, allowing API Providers and administrators to define fine-grained rules that determine whether specific APIs can be discovered and consumed by API Invokers.

This test plan validates the lifecycle of the visibility control rules, ensuring that authentication, authorization logic, and mandatory parameters are correctly enforced.

Test Case 1: Get Visibility Control Rules as Superadmin

Test ID: visibility_control-1

Description: This test case verifies that the Superadmin can retrieve the registered rules. In this case, the response is an empty registry because no rules have been provisioned. It validates the basic connectivity and authentication flow for administrative roles.

Pre-Conditions:

  • The CAPIF helper service is deployed and reachable.
  • Superadmin credentials (SUPERADMIN_USERNAME) are provisioned.
  • The database is in a clean state (no rules existing).

Execution Steps:

  1. Authenticate as Superadmin.
  2. Send a GET request to {apiRoot}/helper/visibility-control/rules.
  3. Inspect the JSON response body.

Expected Result:

  • Status: 200 OK.
  • Body: Returns a JSON object with a rules array. The length of this array must be 0.

Test Case 2: Create Visibility Control Rule with Invalid Dates as Superadmin

Test ID: visibility_control-2

Description: This test case validates the API's logic regarding time-range consistency. A visibility rule must have a logical duration; therefore, the service must reject any attempt to create a rule where the expiration date occurs before the start date.

Pre-Conditions:

  • The CAPIF helper service is deployed and reachable.
  • Superadmin credentials (SUPERADMIN_USERNAME) are provisioned.

Execution Steps:

  1. Authenticate as Superadmin.
  2. Send a POST request to {apiRoot}/helper/visibility-control/rules.
  3. Use a payload where startsAt is later than endsAt (e.g., Starts: 2026, Ends: 2025).

Expected Result:

  • Status: 400 Bad Request.
  • Body: Must contain a ProblemDetails object with the detail field specifying "endsAt must be later than startsAt".

Test Case 3: Create Visibility Control Rule

Test ID: visibility_control-3

Description: This test verifies that the Superadmin can create a rule, obtain its information, and successfully remove it.

Pre-Conditions:

  • The CAPIF helper service is deployed and reachable.
  • Superadmin credentials (SUPERADMIN_USERNAME) are provisioned.
  • A valid RuleCreateRequest payload including the mandatory providerSelector and userName.

Execution Steps:

  1. Authenticate as Superadmin.
  2. Send a POST request to {apiRoot}/helper/visibility-control/rules.
  3. Send a GET request to {apiRoot}/helper/visibility-control/rules.
  4. DELETE the specific rule using the captured ruleId.
  5. GET the rules list again to verify the count returns to zero.

Expected Result:

  • Creation: 201 Created (Body contains the generated ruleId).
  • Listing: 200 OK (List length is 1).
  • Deletion: 204 No Content.

Test Case 4: Get Visibility Control Rule by AMF Provider

Test ID: visibility_control-4

Description: This test case validates that an AMF Provider can list rules and that the system correctly maps the Provider's certificate (CN) to their registered identity to filter the results.

Pre-Conditions:

  • The CAPIF helper service is deployed and reachable.
  • A Provider has been registered and onboarded at CCF.
  • The Provider possesses a valid certificate (in this case AMF certificate).

Execution Steps:

  1. Authenticate using the AMF Provider Certificate.
  2. Send a GET request to {apiRoot}/helper/visibility-control/rules.

Expected Result:

  • Status: 200 OK.
  • Validation: The response body must only contain rules where the requester is the owner (userName).

Test Case 5: Create Visibility Control Rule by AMF Provider and DELETE by superadmin

Test ID: visibility_control-5

Description: This test validates the roles and permissions of Superadmin and Providers to create, delete, and obtain rules.

Pre-Conditions:

  • The CAPIF helper service is deployed and reachable.
  • A Provider has been registered and onboarded at CCF.
  • The Provider possesses a valid certificate (in this case AMF certificate).
  • Superadmin has administrative access.

Execution Steps:

  1. AMF Provider creates a rule: POST request to {apiRoot}/helper/visibility-control/rules.
  2. Superadmin sends a GET request to {apiRoot}/helper/visibility-control/rules.
  3. Superadmin sends a DELETE request for that ruleId.

Expected Result:

  • Provider rule Creation: 201 Created.
  • Superadmin Get: 200 OK.
  • Superadmin Deletion: 204 No Content.
  • Validation: The rule is successfully removed from the database.

Test Case 6: Create and Delete Visibility Control Rule by AMF Provider

Test ID: visibility_control-6

Description: This test validates that the Providers can create, delete, and obtain rules, ensuring that the identity-based authorization logic correctly identifies the owner of a resource and allows them to delete it without requiring Superadmin intervention.

Pre-Conditions:

  • The CAPIF helper service is deployed and reachable.
  • A Provider has been registered and onboarded at CCF.
  • The Provider possesses a valid certificate (in this case AMF certificate).

Execution Steps:

  1. AMF Provider creates a rule: POST request to {apiRoot}/helper/visibility-control/rules.
  2. AMF Provider sends a DELETE request for the same rule using the same provider identity and the ruleId.

Expected Result:

  • Status: 204 No Content.
  • Validation: Subsequent list requests by the provider return an empty set.

Test Case 7: Create Update and Delete Visibility Control Rule by AMF Provider

Test ID: visibility_control-7

Description: This test validates the PATCH implementation. It ensures that Providers can perform partial updates to their rules and that the system correctly updates metadata like updatedAt.

Pre-Conditions:

  • The CAPIF helper service is deployed and reachable.
  • A Provider has been registered and onboarded at CCF.
  • The Provider possesses a valid certificate (in this case AMF certificate).

Execution Steps:

  1. AMF Provider creates a rule: POST request to {apiRoot}/helper/visibility-control/rules.
  2. Send a PATCH request to {apiRoot}/helper/visibility-control/rules/{ruleId}.
  3. Payload: Change default_access from "ALLOW" to "DENY".
  4. Verify the response contains the updated field.
  5. AMF Provider sends a DELETE request for the same rule using the same provider identity and the ruleId.

Expected Result:

  • Status: 200 OK.
  • Body: Returns the updated Rule object showing the new default_access value and a refreshed updatedAt timestamp, and finally the rule is successfully removed.

Test Case 8: Create and Get Specific Visibility Control Rule

Test ID: visibility_control-8

Description: This test verifies the direct resource addressing logic and the error reporting.

Pre-Conditions:

  • The CAPIF helper service is deployed and reachable.
  • Superadmin credentials (SUPERADMIN_USERNAME) are provisioned.

Execution Steps:

  1. Superadmin creates a rule: POST request to {apiRoot}/helper/visibility-control/rules.
  2. Send a GET request for the specific resource via {apiRoot}/helper/visibility-control/rules/{ruleId}.
  3. DELETE the resource.
  4. Perform the same GET request as in step 2.

Expected Result:

  • 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.