Commit b2e68760 authored by Jorge Moratinos's avatar Jorge Moratinos
Browse files

Deployed d3dfbf63 to develop in public with MkDocs 1.6.1 and mike 2.1.3

parent 538757d4

public/develop/releasenotes/index.html

+9 −8
Original line number Diff line number Diff line
@@ -82,7 +82,7 @@ 
    <div data-md-component="skip">

      

        

        <a href="#release-x00" class="md-skip">

        <a href="#release-400" class="md-skip">

          Skip to content

        </a>
@@ -373,15 +373,15 @@ 
    <ul class="md-nav__list" data-md-component="toc" data-md-scrollfix>

      

        <li class="md-nav__item">

  <a href="#release-x00" class="md-nav__link">

  <a href="#release-400" class="md-nav__link">

    <span class="md-ellipsis">

      

        Release X.0.0

        Release 4.0.0

      

    </span>

  </a>

  

    <nav class="md-nav" aria-label="Release X.0.0">

    <nav class="md-nav" aria-label="Release 4.0.0">

      <ul class="md-nav__list">

        

          <li class="md-nav__item">
@@ -2506,15 +2506,15 @@ 
    <ul class="md-nav__list" data-md-component="toc" data-md-scrollfix>

      

        <li class="md-nav__item">

  <a href="#release-x00" class="md-nav__link">

  <a href="#release-400" class="md-nav__link">

    <span class="md-ellipsis">

      

        Release X.0.0

        Release 4.0.0

      

    </span>

  </a>

  

    <nav class="md-nav" aria-label="Release X.0.0">

    <nav class="md-nav" aria-label="Release 4.0.0">

      <ul class="md-nav__list">

        

          <li class="md-nav__item">
@@ -3241,8 +3241,9 @@ 


  <h1>Release Notes</h1>



<h2 id="release-x00"><strong>Release X.0.0</strong></h2>

<h2 id="release-400"><strong>Release 4.0.0</strong></h2>

<h3 id="visibility-control"><strong>Visibility Control</strong></h3>

<p>Current relase includes the initial implementation (Not complete functional) of Visibility Control API. The complete feature implementation is expected to be relased on next OpenCAPIF version, stay tuned!</p>

<h3 id="technical-debt-solved"><strong>Technical Debt Solved</strong></h3>

<h4 id="nginx-configuration-improved"><strong>NGINX Configuration improved</strong></h4>

<p>The NGINX configuration included in the OpenCAPIF deployment has been improved.

public/develop/search/search_index.json

+1 −1

File changed.

Preview size limit exceeded, changes collapsed.

public/develop/testing/testplan/visibility_control/index.html

+141 −93
Original line number Diff line number Diff line
@@ -1879,134 +1879,182 @@ 
<p><strong>Test ID</strong>: <code>visibility_control-1</code></p>

<p><strong>Description</strong>:

This test case verifies that the <strong>Superadmin</strong> 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.</p>

<p><strong>Pre-Conditions</strong>:

* The <strong>CAPIF</strong> helper service is deployed and reachable.

* Superadmin credentials (<code>SUPERADMIN_USERNAME</code>) are provisioned.

* The database is in a clean state (no rules existing).</p>

<p><strong>Execution Steps</strong>:

1. Authenticate as <strong>Superadmin</strong>.

2. Send a <strong>GET</strong> request to <code>{apiRoot}/helper/visibility-control/rules</code>.

3. Inspect the <strong>JSON</strong> response body.</p>

<p><strong>Expected Result</strong>:

* <strong>Status</strong>: <strong>200 OK</strong>.

* <strong>Body</strong>: Returns a <strong>JSON</strong> object with a <code>rules</code> array. The length of this array must be <strong>0</strong>.</p>

<p><strong>Pre-Conditions</strong>:</p>

<ul>

<li>The <strong>CAPIF</strong> helper service is deployed and reachable.</li>

<li>Superadmin credentials (<code>SUPERADMIN_USERNAME</code>) are provisioned.</li>

<li>The database is in a clean state (no rules existing).</li>

</ul>

<p><strong>Execution Steps</strong>:</p>

<ol>

<li>Authenticate as <strong>Superadmin</strong>.</li>

<li>Send a <strong>GET</strong> request to <code>{apiRoot}/helper/visibility-control/rules</code>.</li>

<li>Inspect the <strong>JSON</strong> response body.</li>

</ol>

<p><strong>Expected Result</strong>:</p>

<ul>

<li><strong>Status</strong>: <strong>200 OK</strong>.</li>

<li><strong>Body</strong>: Returns a <strong>JSON</strong> object with a <code>rules</code> array. The length of this array must be <strong>0</strong>.</li>

</ul>

<hr />

<h2 id="test-case-2-create-visibility-control-rule-with-invalid-dates-as-superadmin">Test Case 2: Create Visibility Control Rule with Invalid Dates as Superadmin</h2>

<p><strong>Test ID</strong>: <code>visibility_control-2</code></p>

<p><strong>Description</strong>:

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.</p>

<p><strong>Pre-Conditions</strong>:

* The <strong>CAPIF</strong> helper service is deployed and reachable.

* Superadmin credentials (<code>SUPERADMIN_USERNAME</code>) are provisioned.</p>

<p><strong>Execution Steps</strong>:

1. Authenticate as <strong>Superadmin</strong>.

2. Send a <strong>POST</strong> request to <code>{apiRoot}/helper/visibility-control/rules</code>.

3. Use a payload where <code>startsAt</code> is later than <code>endsAt</code> (e.g., Starts: <code>2026</code>, Ends: <code>2025</code>).</p>

<p><strong>Expected Result</strong>:

* <strong>Status</strong>: <strong>400 Bad Request</strong>.

* <strong>Body</strong>: Must contain a <code>ProblemDetails</code> object with the <code>detail</code> field specifying <strong>"endsAt must be later than startsAt"</strong>.</p>

<p><strong>Pre-Conditions</strong>:</p>

<ul>

<li>The <strong>CAPIF</strong> helper service is deployed and reachable.</li>

<li>Superadmin credentials (<code>SUPERADMIN_USERNAME</code>) are provisioned.</li>

</ul>

<p><strong>Execution Steps</strong>:</p>

<ol>

<li>Authenticate as <strong>Superadmin</strong>.</li>

<li>Send a <strong>POST</strong> request to <code>{apiRoot}/helper/visibility-control/rules</code>.</li>

<li>Use a payload where <code>startsAt</code> is later than <code>endsAt</code> (e.g., Starts: <code>2026</code>, Ends: <code>2025</code>).</li>

</ol>

<p><strong>Expected Result</strong>:</p>

<ul>

<li><strong>Status</strong>: <strong>400 Bad Request</strong>.</li>

<li><strong>Body</strong>: Must contain a <code>ProblemDetails</code> object with the <code>detail</code> field specifying <strong>"endsAt must be later than startsAt"</strong>.</li>

</ul>

<hr />

<h2 id="test-case-3-create-visibility-control-rule">Test Case 3: Create Visibility Control Rule</h2>

<p><strong>Test ID</strong>: <code>visibility_control-3</code></p>

<p><strong>Description</strong>:

This test verifies that the <strong>Superadmin</strong> can create a rule, obtain its information, and successfully remove it.</p>

<p><strong>Pre-Conditions</strong>:

* The <strong>CAPIF</strong> helper service is deployed and reachable.

* Superadmin credentials (<code>SUPERADMIN_USERNAME</code>) are provisioned.

* A valid <code>RuleCreateRequest</code> payload including the mandatory <code>providerSelector</code> and <code>userName</code>.</p>

<p><strong>Execution Steps</strong>:

1. Authenticate as <strong>Superadmin</strong>.

2. Send a <strong>POST</strong> request to <code>{apiRoot}/helper/visibility-control/rules</code>.

3. Send a <strong>GET</strong> request to <code>{apiRoot}/helper/visibility-control/rules</code>.

4. <strong>DELETE</strong> the specific rule using the captured <code>ruleId</code>.

5. <strong>GET</strong> the rules list again to verify the count returns to zero.</p>

<p><strong>Expected Result</strong>:

* <strong>Creation</strong>: <strong>201 Created</strong> (Body contains the generated <code>ruleId</code>).

* <strong>Listing</strong>: <strong>200 OK</strong> (List length is <strong>1</strong>).

* <strong>Deletion</strong>: <strong>204 No Content</strong>.</p>

<p><strong>Pre-Conditions</strong>:</p>

<ul>

<li>The <strong>CAPIF</strong> helper service is deployed and reachable.</li>

<li>Superadmin credentials (<code>SUPERADMIN_USERNAME</code>) are provisioned.</li>

<li>A valid <code>RuleCreateRequest</code> payload including the mandatory <code>providerSelector</code> and <code>userName</code>.</li>

</ul>

<p><strong>Execution Steps</strong>:</p>

<ol>

<li>Authenticate as <strong>Superadmin</strong>.</li>

<li>Send a <strong>POST</strong> request to <code>{apiRoot}/helper/visibility-control/rules</code>.</li>

<li>Send a <strong>GET</strong> request to <code>{apiRoot}/helper/visibility-control/rules</code>.</li>

<li><strong>DELETE</strong> the specific rule using the captured <code>ruleId</code>.</li>

<li><strong>GET</strong> the rules list again to verify the count returns to zero.</li>

</ol>

<p><strong>Expected Result</strong>:</p>

<ul>

<li><strong>Creation</strong>: <strong>201 Created</strong> (Body contains the generated <code>ruleId</code>).</li>

<li><strong>Listing</strong>: <strong>200 OK</strong> (List length is <strong>1</strong>).</li>

<li><strong>Deletion</strong>: <strong>204 No Content</strong>.</li>

</ul>

<hr />

<h2 id="test-case-4-get-visibility-control-rule-by-amf-provider">Test Case 4: Get Visibility Control Rule by AMF Provider</h2>

<p><strong>Test ID</strong>: <code>visibility_control-4</code></p>

<p><strong>Description</strong>:

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

<p><strong>Pre-Conditions</strong>:

* The <strong>CAPIF</strong> helper service is deployed and reachable.

* A <strong>Provider</strong> has been registered and onboarded at <strong>CCF</strong>.

* The <strong>Provider</strong> possesses a valid certificate (in this case <strong>AMF</strong> certificate).</p>

<p><strong>Execution Steps</strong>:

1. Authenticate using the <strong>AMF Provider Certificate</strong>.

2. Send a <strong>GET</strong> request to <code>{apiRoot}/helper/visibility-control/rules</code>.</p>

<p><strong>Expected Result</strong>:

* <strong>Status</strong>: <strong>200 OK</strong>.

* <strong>Validation</strong>: The response body must only contain rules where the requester is the owner (<code>userName</code>).</p>

<p><strong>Pre-Conditions</strong>:</p>

<ul>

<li>The <strong>CAPIF</strong> helper service is deployed and reachable.</li>

<li>A <strong>Provider</strong> has been registered and onboarded at <strong>CCF</strong>.</li>

<li>The <strong>Provider</strong> possesses a valid certificate (in this case <strong>AMF</strong> certificate).</li>

</ul>

<p><strong>Execution Steps</strong>:</p>

<ol>

<li>Authenticate using the <strong>AMF Provider Certificate</strong>.</li>

<li>Send a <strong>GET</strong> request to <code>{apiRoot}/helper/visibility-control/rules</code>.</li>

</ol>

<p><strong>Expected Result</strong>:</p>

<ul>

<li><strong>Status</strong>: <strong>200 OK</strong>.</li>

<li><strong>Validation</strong>: The response body must only contain rules where the requester is the owner (<code>userName</code>).</li>

</ul>

<hr />

<h2 id="test-case-5-create-visibility-control-rule-by-amf-provider-and-delete-by-superadmin">Test Case 5: Create Visibility Control Rule by AMF Provider and DELETE by superadmin</h2>

<p><strong>Test ID</strong>: <code>visibility_control-5</code></p>

<p><strong>Description</strong>:

This test validates the roles and permissions of <strong>Superadmin</strong> and <strong>Providers</strong> to create, delete, and obtain rules.</p>

<p><strong>Pre-Conditions</strong>:

* The <strong>CAPIF</strong> helper service is deployed and reachable.

* A <strong>Provider</strong> has been registered and onboarded at <strong>CCF</strong>.

* The <strong>Provider</strong> possesses a valid certificate (in this case <strong>AMF</strong> certificate).

* <strong>Superadmin</strong> has administrative access.</p>

<p><strong>Execution Steps</strong>:

1. <strong>AMF Provider</strong> creates a rule: <strong>POST</strong> request to <code>{apiRoot}/helper/visibility-control/rules</code>.

2. <strong>Superadmin</strong> sends a <strong>GET</strong> request to <code>{apiRoot}/helper/visibility-control/rules</code>.

3. <strong>Superadmin</strong> sends a <strong>DELETE</strong> request for that <code>ruleId</code>.</p>

<p><strong>Expected Result</strong>:

* <strong>Provider rule Creation</strong>: <strong>201 Created</strong>.

* <strong>Superadmin Get</strong>: <strong>200 OK</strong>.

* <strong>Superadmin Deletion</strong>: <strong>204 No Content</strong>.

* <strong>Validation</strong>: The rule is successfully removed from the database.</p>

<p><strong>Pre-Conditions</strong>:</p>

<ul>

<li>The <strong>CAPIF</strong> helper service is deployed and reachable.</li>

<li>A <strong>Provider</strong> has been registered and onboarded at <strong>CCF</strong>.</li>

<li>The <strong>Provider</strong> possesses a valid certificate (in this case <strong>AMF</strong> certificate).</li>

<li><strong>Superadmin</strong> has administrative access.</li>

</ul>

<p><strong>Execution Steps</strong>:</p>

<ol>

<li><strong>AMF Provider</strong> creates a rule: <strong>POST</strong> request to <code>{apiRoot}/helper/visibility-control/rules</code>.</li>

<li><strong>Superadmin</strong> sends a <strong>GET</strong> request to <code>{apiRoot}/helper/visibility-control/rules</code>.</li>

<li><strong>Superadmin</strong> sends a <strong>DELETE</strong> request for that <code>ruleId</code>.</li>

</ol>

<p><strong>Expected Result</strong>:</p>

<ul>

<li><strong>Provider rule Creation</strong>: <strong>201 Created</strong>.</li>

<li><strong>Superadmin Get</strong>: <strong>200 OK</strong>.</li>

<li><strong>Superadmin Deletion</strong>: <strong>204 No Content</strong>.</li>

<li><strong>Validation</strong>: The rule is successfully removed from the database.</li>

</ul>

<hr />

<h2 id="test-case-6-create-and-delete-visibility-control-rule-by-amf-provider">Test Case 6: Create and Delete Visibility Control Rule by AMF Provider</h2>

<p><strong>Test ID</strong>: <code>visibility_control-6</code></p>

<p><strong>Description</strong>:

This test validates that the <strong>Providers</strong> 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 <strong>Superadmin</strong> intervention.</p>

<p><strong>Pre-Conditions</strong>:

* The <strong>CAPIF</strong> helper service is deployed and reachable.

* A <strong>Provider</strong> has been registered and onboarded at <strong>CCF</strong>.

* The <strong>Provider</strong> possesses a valid certificate (in this case <strong>AMF</strong> certificate).</p>

<p><strong>Execution Steps</strong>:

1. <strong>AMF Provider</strong> creates a rule: <strong>POST</strong> request to <code>{apiRoot}/helper/visibility-control/rules</code>.

2. <strong>AMF Provider</strong> sends a <strong>DELETE</strong> request for the same rule using the same provider identity and the <code>ruleId</code>.</p>

<p><strong>Expected Result</strong>:

* <strong>Status</strong>: <strong>204 No Content</strong>.

* <strong>Validation</strong>: Subsequent list requests by the provider return an empty set.</p>

<p><strong>Pre-Conditions</strong>:</p>

<ul>

<li>The <strong>CAPIF</strong> helper service is deployed and reachable.</li>

<li>A <strong>Provider</strong> has been registered and onboarded at <strong>CCF</strong>.</li>

<li>The <strong>Provider</strong> possesses a valid certificate (in this case <strong>AMF</strong> certificate).</li>

</ul>

<p><strong>Execution Steps</strong>:</p>

<ol>

<li><strong>AMF Provider</strong> creates a rule: <strong>POST</strong> request to <code>{apiRoot}/helper/visibility-control/rules</code>.</li>

<li><strong>AMF Provider</strong> sends a <strong>DELETE</strong> request for the same rule using the same provider identity and the <code>ruleId</code>.</li>

</ol>

<p><strong>Expected Result</strong>:</p>

<ul>

<li><strong>Status</strong>: <strong>204 No Content</strong>.</li>

<li><strong>Validation</strong>: Subsequent list requests by the provider return an empty set.</li>

</ul>

<hr />

<h2 id="test-case-7-create-update-and-delete-visibility-control-rule-by-amf-provider">Test Case 7: Create Update and Delete Visibility Control Rule by AMF Provider</h2>

<p><strong>Test ID</strong>: <code>visibility_control-7</code></p>

<p><strong>Description</strong>:

This test validates the <strong>PATCH</strong> implementation. It ensures that <strong>Providers</strong> can perform partial updates to their rules and that the system correctly updates metadata like <code>updatedAt</code>.</p>

<p><strong>Pre-Conditions</strong>:

* The <strong>CAPIF</strong> helper service is deployed and reachable.

* A <strong>Provider</strong> has been registered and onboarded at <strong>CCF</strong>.

* The <strong>Provider</strong> possesses a valid certificate (in this case <strong>AMF</strong> certificate).</p>

<p><strong>Execution Steps</strong>:

1. <strong>AMF Provider</strong> creates a rule: <strong>POST</strong> request to <code>{apiRoot}/helper/visibility-control/rules</code>.

2. Send a <strong>PATCH</strong> request to <code>{apiRoot}/helper/visibility-control/rules/{ruleId}</code>.

3. <strong>Payload</strong>: Change <code>default_access</code> from <strong>"ALLOW"</strong> to <strong>"DENY"</strong>.

4. Verify the response contains the updated field.

5. <strong>AMF Provider</strong> sends a <strong>DELETE</strong> request for the same rule using the same provider identity and the <code>ruleId</code>.</p>

<p><strong>Expected Result</strong>:

* <strong>Status</strong>: <strong>200 OK</strong>.

* <strong>Body</strong>: Returns the updated <code>Rule</code> object showing the new <code>default_access</code> value and a refreshed <code>updatedAt</code> timestamp, and finally the rule is successfully removed.</p>

<p><strong>Pre-Conditions</strong>:</p>

<ul>

<li>The <strong>CAPIF</strong> helper service is deployed and reachable.</li>

<li>A <strong>Provider</strong> has been registered and onboarded at <strong>CCF</strong>.</li>

<li>The <strong>Provider</strong> possesses a valid certificate (in this case <strong>AMF</strong> certificate).</li>

</ul>

<p><strong>Execution Steps</strong>:</p>

<ol>

<li><strong>AMF Provider</strong> creates a rule: <strong>POST</strong> request to <code>{apiRoot}/helper/visibility-control/rules</code>.</li>

<li>Send a <strong>PATCH</strong> request to <code>{apiRoot}/helper/visibility-control/rules/{ruleId}</code>.</li>

<li><strong>Payload</strong>: Change <code>default_access</code> from <strong>"ALLOW"</strong> to <strong>"DENY"</strong>.</li>

<li>Verify the response contains the updated field.</li>

<li><strong>AMF Provider</strong> sends a <strong>DELETE</strong> request for the same rule using the same provider identity and the <code>ruleId</code>.</li>

</ol>

<p><strong>Expected Result</strong>:</p>

<ul>

<li><strong>Status</strong>: <strong>200 OK</strong>.</li>

<li><strong>Body</strong>: Returns the updated <code>Rule</code> object showing the new <code>default_access</code> value and a refreshed <code>updatedAt</code> timestamp, and finally the rule is successfully removed.</li>

</ul>

<hr />

<h2 id="test-case-8-create-and-get-specific-visibility-control-rule">Test Case 8: Create and Get Specific Visibility Control Rule</h2>

<p><strong>Test ID</strong>: <code>visibility_control-8</code></p>

<p><strong>Description</strong>:

This test verifies the direct resource addressing logic and the error reporting.</p>

<p><strong>Pre-Conditions</strong>:

* The <strong>CAPIF</strong> helper service is deployed and reachable.

* Superadmin credentials (<code>SUPERADMIN_USERNAME</code>) are provisioned.</p>

<p><strong>Execution Steps</strong>:

1. <strong>Superadmin</strong> creates a rule: <strong>POST</strong> request to <code>{apiRoot}/helper/visibility-control/rules</code>.

2. Send a <strong>GET</strong> request for the specific resource via <code>{apiRoot}/helper/visibility-control/rules/{ruleId}</code>.

3. <strong>DELETE</strong> the resource.

4. Perform the same <strong>GET</strong> request as in step 2.</p>

<p><strong>Expected Result</strong>:

* <strong>Step 2</strong>: <strong>200 OK</strong> (Returns the specific rule object).

* <strong>Step 4</strong>: <strong>404 Not Found</strong> (Ensures the resource no longer exists in the registry).</p>

<p><strong>Pre-Conditions</strong>:</p>

<ul>

<li>The <strong>CAPIF</strong> helper service is deployed and reachable.</li>

<li>Superadmin credentials (<code>SUPERADMIN_USERNAME</code>) are provisioned.</li>

</ul>

<p><strong>Execution Steps</strong>:</p>

<ol>

<li><strong>Superadmin</strong> creates a rule: <strong>POST</strong> request to <code>{apiRoot}/helper/visibility-control/rules</code>.</li>

<li>Send a <strong>GET</strong> request for the specific resource via <code>{apiRoot}/helper/visibility-control/rules/{ruleId}</code>.</li>

<li><strong>DELETE</strong> the resource.</li>

<li>Perform the same <strong>GET</strong> request as in step 2.</li>

</ol>

<p><strong>Expected Result</strong>:</p>

<ul>

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