Test Case 12: Discover Published service APIs by Unauthorised API Invoker Visibility Control (update the rule and see changes in the discovery process)
</span>
</a>
</li>
</ul>
@@ -2139,6 +2183,123 @@ This test verifies the direct resource addressing logic and the error reporting.
<li><strong>Step 2</strong>: <strong>200 OK</strong> (Returns the specific rule object).</li>
<li><strong>Step 4</strong>: <strong>404 Not Found</strong> (Ensures the resource no longer exists in the registry).</li>
</ul>
<h2id="test-case-9-discover-published-service-apis-by-unauthorised-api-invoker-visibility-control">Test Case 9: Discover Published service APIs by Unauthorised API Invoker Visibility Control</h2>
This test case verifies that an <strong>Invoker</strong> 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.</p>
<p><strong>Pre-Conditions</strong>:</p>
<ul>
<li>The <strong>CAPIF</strong> services are deployed and reachable.</li>
<li>A <strong>Provider</strong> has been registered and onboarded at <strong>CCF</strong>.</li>
<li>A service API is published by the provider.</li>
<li>An <strong>Invoker</strong> is registered and onboarded at <strong>CCF</strong>.</li>
<li>Superadmin credentials (<code>SUPERADMIN_USERNAME</code>) are provisioned.</li>
</ul>
<p><strong>Execution Steps</strong>:</p>
<ol>
<li>Authenticate as <strong>Invoker</strong> and send a <strong>GET</strong> request to the Discovery API to ensure the published API is initially visible.</li>
<li>Authenticate as <strong>Superadmin</strong>.</li>
<li>Send a <strong>POST</strong> request to <code>{apiRoot}/helper/visibility-control/rules</code> to create a rule that hides the API for this specific <strong>API Invoker</strong>.</li>
<li>Authenticate as <strong>Invoker</strong> and send a <strong>GET</strong> request to the Discovery API again. </li>
<li><strong>Superadmin</strong> sends a <strong>DELETE</strong> request for the created <code>ruleId</code>.</li>
<li><strong>Superadmin</strong> sends a <strong>GET</strong> request to the rules list to verify it is empty.</li>
</ol>
<p><strong>Expected Result</strong>:</p>
<ul>
<li><strong>Initial Discovery</strong>: <strong>200 OK</strong> (The API is discovered).</li>
<li><strong>Second Discovery</strong>: <strong>404 Not Found</strong>. The response body must contain a <code>ProblemDetails</code> object with the <code>detail</code> specifying <strong>"API Invoker {invoker_id} has no visible APIs after applying visibility rules"</strong>.</li>
<li><strong>Rule Deletion</strong>: <strong>204 No Content</strong>.</li>
<li><strong>Final List</strong>: <strong>200 OK</strong> (List length is <strong>0</strong>).</li>
</ul>
<hr/>
<h2id="test-case-10-discover-published-service-apis-by-unauthorised-api-invoker-visibility-control-two-apis">Test Case 10: Discover Published service APIs by Unauthorised API Invoker Visibility Control (two APIs)</h2>
This test case validates the discovery process when a <strong>Provider</strong> has published multiple APIs. It verifies that applying an explicit visibility rule to <strong>deny</strong> access to one specific API correctly hides only that targeted API from the <strong>Invoker</strong>, while any other published APIs remain unaffected and fully discoverable.</p>
<p><strong>Pre-Conditions</strong>:</p>
<ul>
<li>The <strong>CAPIF</strong> services are deployed and reachable.</li>
<li>A <strong>Provider</strong> is registered and onboarded at <strong>CCF</strong>.</li>
<li><strong>Two</strong> distinct service APIs are published by the same provider.</li>
<li>An <strong>Invoker</strong> is registered and onboarded at <strong>CCF</strong>.</li>
<li>Superadmin credentials (<code>SUPERADMIN_USERNAME</code>) are provisioned.</li>
</ul>
<p><strong>Execution Steps</strong>:</p>
<ol>
<li>Authenticate as <strong>Invoker</strong> and send a <strong>GET</strong> request to the Discovery API to ensure both APIs are initially visible.</li>
<li>Authenticate as <strong>Superadmin</strong>.</li>
<li>Send a <strong>POST</strong> request to <code>{apiRoot}/helper/visibility-control/rules</code> creating a rule that targets only <strong>one</strong> of the published APIs for the invoker.</li>
<li>Authenticate as <strong>API Invoker</strong> and send a <strong>GET</strong> request to the Discovery API again.</li>
<li><strong>Superadmin</strong> sends a <strong>DELETE</strong> request for the created <code>ruleId</code>.</li>
</ol>
<p><strong>Expected Result</strong>:</p>
<ul>
<li><strong>First Discovery</strong>: <strong>200 OK</strong> (List length of the discovery APIs <code>serviceAPIDescriptions</code> is <strong>2</strong>).</li>
<li><strong>Second Discovery</strong>: <strong>200 OK</strong>. The <code>serviceAPIDescriptions</code> list length must be <strong>1</strong>, containing the targeted API and explicitly not containing the denied API.</li>
<li><strong>Rule Deletion</strong>: <strong>204 No Content</strong>.</li>
</ul>
<hr/>
<h2id="test-case-11-discover-published-service-apis-by-unauthorised-api-invoker-visibility-control-having-several-rules">Test Case 11: Discover Published service APIs by Unauthorised API Invoker Visibility Control (having several rules)</h2>
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.</p>
<p><strong>Pre-Conditions</strong>:</p>
<ul>
<li>The <strong>CAPIF</strong> services are deployed and reachable.</li>
<li>A <strong>Provider</strong> is registered and onboarded at <strong>CCF</strong>.</li>
<li><strong>Two</strong> distinct service APIs are published by the same provider.</li>
<li>An <strong>Invoker</strong> is registered and onboarded at <strong>CCF</strong>.</li>
<li>Superadmin credentials (<code>SUPERADMIN_USERNAME</code>) are provisioned.</li>
</ul>
<p><strong>Execution Steps</strong>:</p>
<ol>
<li>Authenticate as <strong>Invoker</strong> and send a <strong>GET</strong> request to the Discovery API to ensure the API is visible.</li>
<li>Authenticate as <strong>Superadmin</strong> and create a first visibility rule (blocking discovery) for the <strong>API Invoker</strong>.</li>
<li><strong>API Invoker</strong> sends a <strong>GET</strong> request to the Discovery API.</li>
<li><strong>Superadmin</strong> creates a second visibility rule (allowing discovery) for the same <strong>Invoker</strong> and API.</li>
<li><strong>API Invoker</strong> sends a <strong>GET</strong> request to the Discovery API again.</li>
<li><strong>Second Discovery (Blocked)</strong>: <strong>404 Not Found</strong> with <code>detail</code> specifying <strong>"API Invoker {invoker_id} has no visible APIs after applying visibility rules"</strong>.</li>
<li><strong>Third Discovery (Allowed)</strong>: <strong>200 OK</strong> (List length is <strong>1</strong>, containing the published API).</li>
</ul>
<hr/>
<h2id="test-case-12-discover-published-service-apis-by-unauthorised-api-invoker-visibility-control-update-the-rule-and-see-changes-in-the-discovery-process">Test Case 12: Discover Published service APIs by Unauthorised API Invoker Visibility Control (update the rule and see changes in the discovery process)</h2>
This test validates the dynamic application of rule modifications. It ensures that updating a rule's <code>enabled</code> state via a <strong>PATCH</strong> request immediately affects the discovery process for API Invokers.</p>
<p><strong>Pre-Conditions</strong>:</p>
<ul>
<li>The <strong>CAPIF</strong> services are deployed and reachable.</li>
<li>A <strong>Provider</strong> is registered and onboarded at <strong>CCF</strong>.</li>
<li><strong>Two</strong> distinct service APIs are published by the same provider.</li>
<li>An <strong>Invoker</strong> is registered and onboarded at <strong>CCF</strong>.</li>
<li>Superadmin credentials (<code>SUPERADMIN_USERNAME</code>) are provisioned.</li>
</ul>
<p><strong>Execution Steps</strong>:</p>
<ol>
<li>Authenticate as <strong>Invoker</strong> and send a <strong>GET</strong> request to the Discovery API to ensure the API is visible.</li>
<li>Authenticate as <strong>Superadmin</strong> and create a rule that hides the API.</li>
<li><strong>API Invoker</strong> sends a <strong>GET</strong> request to the Discovery API.</li>
<li><strong>Superadmin</strong> sends a <strong>PATCH</strong> request to <code>{apiRoot}/helper/visibility-control/rules/{ruleId}</code> changing the <code>enabled</code> field to <strong>False</strong>.</li>
<li><strong>API Invoker</strong> sends a <strong>GET</strong> request to the Discovery API again.</li>
<li><strong>Superadmin</strong> sends a <strong>DELETE</strong> request for the <code>ruleId</code>.</li>
<li><strong>Discovery (Rule Enabled)</strong>: <strong>404 Not Found</strong> with <code>detail</code> specifying <strong>"API Invoker {invoker_id} has no visible APIs after applying visibility rules"</strong>.</li>
