Test Plan for CAPIF Interconnection Service

At this documentation you will have all information and related files and examples of test plan for the interconnection functionality between multiple CCFs (CAPIF Core Functions).

Test Case 1: Interconnection Request between CCF-A and CCF-B

Test ID: interconnection-1

Description:

This test case validates that a SuperAdmin can establish and delete an interconnection request between two CCFs.

Pre-Conditions:

• SuperAdmin is authenticated and authorized to perform interconnection operations
• Two CCF instances (CCF-A and CCF-B) are running and accessible

Execution Steps:

1. Get CCF-A identifier
2. Create interconnection request to CCF-B
3. Delete the established interconnection

Information of Test:

1. Get CCF-A ID:

   • Get the unique identifier for the current CCF (CCF-A)

2. Create Interconnection Request:

   • Send POST https://{CAPIF_HOSTNAME}/helper/interconnection/request
   • body interconnection body with destination CCF hostname capifcore-b:1443
   • Use SuperAdmin Certificate
   • Target server: {CAPIF_HOSTNAME}

3. Delete Interconnection:

   • Send DELETE https://{CAPIF_HOSTNAME}/helper/interconnection/request/{ccfId}
   • Use SuperAdmin Certificate
   • Target server: {CAPIF_HOSTNAME}

Expected Result:

1. Create interconnection request:

   1. 201 Created response
   2. Response body contains ccfId for the connected CCF-B
   3. Response is logged for verification

2. Delete interconnection:

   1. 204 No Content response
   2. Interconnection is successfully removed

Test Case 2: Interconnection Request between CCF-A and CCF-B with one API published on CCF-A capifProvDoms not present

Test ID: interconnection-2

Description:

This test case verifies that when an API is published on CCF-A without specifying capifProvDoms, it can be discovered on CCF-B after interconnection is established. The API should be accessible through the interconnection automatically.

Pre-Conditions:

• Provider is pre-authorised at CCF-A
• API Invoker is pre-authorised at both CCF-A and CCF-B
• Interconnection between CCF-A and CCF-B is operational

Execution Steps:

1. Register Provider at CCF-A
2. Publish a shareable Service API at CCF-A (without capifProvDoms configuration)
3. Register and onboard Invoker at CCF-A
4. Discover published APIs at CCF-A
5. Establish interconnection between CCF-A and CCF-B
6. Register and onboard Invoker at CCF-B
7. Discover published APIs at CCF-B with aef-id filter from CCF-A provider

Information of Test:

1. Provider Registration and API Publication at CCF-A:

   • Perform Provider Registration
   • Send POST https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis
   • body service api description with is_shareable=True
   • Use APF Certificate

2. Invoker Onboarding at CCF-A:

   • Perform Invoker Onboarding

3. Discover APIs at CCF-A:

   • Send GET https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id={aefId}
   • Use Invoker Certificate
   • Expected: DiscoveredAPIs with 1 service

4. Create Interconnection:

   • Send POST https://{CAPIF_HOSTNAME}/helper/interconnection/request
   • body interconnection body with CCF-B hostname
   • Use SuperAdmin Certificate

5. Invoker Onboarding at CCF-B:

   • Perform Invoker Onboarding with parameters:
   • invoker_username: {INVOKER_USERNAME}_B
   • register_server: https://{INTERCONNECTION_CCF_REGISTER_HOSTNAME}/
   • capif_server: https://{INTERCONNECTION_CCF_HOSTNAME}/

6. Discover APIs at CCF-B:

   • Send GET https://{INTERCONNECTION_CCF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id={aefIdFromCCFA}
   • Use {INVOKER_USERNAME}_B Certificate
   • Target server: {INTERCONNECTION_CCF_HOSTNAME}

Expected Result:

1. API Discovery at CCF-A:

   1. 200 OK response
   2. Response body accomplishes DiscoveredAPIs data structure
   3. serviceAPIDescriptions array contains 1 API entry
   4. API details match the published service API

2. API Discovery at CCF-B:

   1. 200 OK response
   2. Response body accomplishes DiscoveredAPIs data structure
   3. serviceAPIDescriptions array contains 1 API entry
   4. pubApiPath.ccfIds contains CCF-A identifier
   5. API is accessible through interconnection

Test Case 3: Interconnection Request between CCF-A and CCF-B with one API published on CCF-A capifProvDoms present with CCF-B hostname

Test ID: interconnection-3

Description:

This test case validates that when an API is published on CCF-A with capifProvDoms explicitly set to include CCF-B hostname, the API is discoverable on CCF-B after interconnection. The API publication includes the target CCF domain before establishing interconnection.

Pre-Conditions:

• Provider is pre-authorised at CCF-A
• API Invoker is pre-authorised at both CCF-A and CCF-B
• CCF-B hostname is known before API publication

Execution Steps:

1. Register Provider at CCF-A
2. Publish a shareable Service API at CCF-A with capifProvDoms set to CCF-B hostname
3. Register and onboard Invoker at CCF-A
4. Discover published APIs at CCF-A to verify publication
5. Establish interconnection between CCF-A and CCF-B
6. Register and onboard Invoker at CCF-B
7. Discover published APIs at CCF-B with aef-id filter from CCF-A provider

Information of Test:

1. Provider Registration at CCF-A:

   • Perform Provider Registration

2. Publish API with capifProvDoms at CCF-A:

   • Send POST https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis
   • body service api description with:
   • is_shareable=True
   • capif_prov_doms=capifcore-b:1443
   • Use APF Certificate

3. Invoker Onboarding at CCF-A:

   • Perform Invoker Onboarding

4. Discover APIs at CCF-A:

   • Send GET https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id={aefId}
   • Use Invoker Certificate
   • Expected: DiscoveredAPIs with 1 service matching the published API

5. Create Interconnection:

   • Send POST https://{CAPIF_HOSTNAME}/helper/interconnection/request
   • body interconnection body with CCF-B hostname capifcore-b:1443
   • Use SuperAdmin Certificate

6. Invoker Onboarding at CCF-B:

   • Perform Invoker Onboarding with parameters:
   • invoker_username: {INVOKER_USERNAME}_B
   • register_server: https://register-b:8184/
   • capif_server: https://capifcore-b:1443/

7. Discover APIs at CCF-B:

   • Send GET https://capifcore-b:1443/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id={aefIdFromCCFA}
   • Use {INVOKER_USERNAME}_B Certificate
   • Target server: https://capifcore-b:1443/

Expected Result:

1. API Publication at CCF-A:

   1. 201 Created response
   2. Response body accomplishes ServiceAPIDescription data structure

2. API Discovery at CCF-A:

   1. 200 OK response
   2. serviceAPIDescriptions array contains 1 entry
   3. Entry matches the published API details

3. API Discovery at CCF-B:

   1. 200 OK response
   2. Response body accomplishes DiscoveredAPIs data structure
   3. serviceAPIDescriptions array contains 1 entry
   4. pubApiPath.ccfIds array is not empty
   5. pubApiPath.ccfIds contains CCF-A identifier
   6. API is accessible through the pre-configured interconnection path

Test Case 4: Interconnection Request between CCF-A and CCF-B with one API published on CCF-A capifProvDoms present with OTHER hostname

Test ID: interconnection-4

Description:

This test case validates that when an API is published with capifProvDoms set to a hostname different from the actual CCF-B hostname, invokers on CCF-B cannot discover the API even after interconnection is established.

Pre-Conditions:

• Provider is pre-authorised at CCF-A
• API Invoker is pre-authorised at both CCF-A and CCF-B
• Interconnection between CCF-A and CCF-B is established

Execution Steps:

1. Register Provider at CCF-A
2. Publish a shareable Service API at CCF-A with capifProvDoms set to "OTHER" (not CCF-B hostname)
3. Register and onboard Invoker at CCF-A
4. Discover published APIs at CCF-A
5. Establish interconnection between CCF-A and CCF-B
6. Register and onboard Invoker at CCF-B
7. Attempt to discover the API at CCF-B with same aef-id filter

Information of Test:

1. Provider Registration at CCF-A:

   • Perform Provider Registration

2. Publish API with capifProvDoms=OTHER:

   • Send POST https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis
   • body service api description with:
   • is_shareable=True
   • capif_prov_doms=OTHER
   • Use APF Certificate

3. Invoker Onboarding at CCF-A:

   • Perform Invoker Onboarding

4. Discover APIs at CCF-A:

   • Send GET https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id={aefId}
   • Use Invoker Certificate

5. Create Interconnection:

   • Send POST https://{CAPIF_HOSTNAME}/helper/interconnection/request
   • body interconnection body with CCF-B hostname
   • Use SuperAdmin Certificate

6. Invoker Onboarding at CCF-B:

   • Perform Invoker Onboarding with parameters:
   • invoker_username: {INVOKER_USERNAME}_B
   • register_server: https://register-b:8184/
   • capif_server: https://capifcore-b:1443/

7. Attempt Discovery at CCF-B:

   • Send GET https://capifcore-b:1443/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id={aefIdFromCCFA}
   • Use {INVOKER_USERNAME}_B Certificate
   • Target server: https://capifcore-b:1443/

Expected Result:

1. API Discovery at CCF-A:

   1. 200 OK response
   2. serviceAPIDescriptions array contains 1 entry

2. API Discovery attempt at CCF-B:

   1. 404 Not Found response
   2. Response body accomplishes ProblemDetails data structure with:
      • title: "Not Found"
      • status: 404
      • detail: "API Invoker {apiInvokerId} has no API Published that accomplish filter conditions"
      • cause: "No API Published accomplish filter conditions"
   3. API is NOT accessible because capifProvDoms mismatch excludes this CCF

Test Case 5: Publish API after CAPIFs Interconnection with capifProvDoms present with CCF-B hostname

Test ID: interconnection-5

Description:

This test case verifies that APIs published AFTER interconnection is established are immediately accessible on the remote CCF if capifProvDoms includes the remote CCF hostname.

Pre-Conditions:

• Interconnection between CCF-A and CCF-B is already established
• Provider is pre-authorised at CCF-A
• API Invoker is pre-authorised at CCF-B

Execution Steps:

1. Get CCF-A identifier
2. Establish interconnection between CCF-A and CCF-B
3. Register Provider at CCF-A
4. Publish a shareable Service API at CCF-A with capifProvDoms set to CCF-B hostname
5. Register and onboard Invoker at CCF-B
6. Discover published APIs at CCF-B immediately after publication

Information of Test:

1. Get CCF-A ID and Create Interconnection:

   • Get CCF-A identifier
   • Send POST https://{CAPIF_HOSTNAME}/helper/interconnection/request
   • body interconnection body with CCF-B hostname
   • Use SuperAdmin Certificate

2. Provider Registration at CCF-A:

   • Perform Provider Registration

3. Publish API after interconnection:

   • Send POST https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis
   • body service api description with:
   • is_shareable=True
   • capif_prov_doms=capifcore-b:1443
   • Use APF Certificate

4. Invoker Onboarding at CCF-B:

   • Perform Invoker Onboarding with parameters:
   • invoker_username: {INVOKER_USERNAME}_B
   • register_server: https://register-b:8184/
   • capif_server: https://capifcore-b:1443/

5. Discover APIs at CCF-B:

   • Send GET https://capifcore-b:1443/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id={aefIdFromCCFA}
   • Use {INVOKER_USERNAME}_B Certificate
   • Target server: https://capifcore-b:1443/

Expected Result:

1. Interconnection Creation:

   1. 201 Created response
   2. Response body contains valid ccfId

2. API Publication:

   1. 201 Created response

3. API Discovery at CCF-B:

   1. 200 OK response
   2. Response body accomplishes DiscoveredAPIs data structure
   3. serviceAPIDescriptions array contains 1 entry
   4. pubApiPath.ccfIds is not empty
   5. pubApiPath.ccfIds contains CCF-A identifier
   6. API published after interconnection is immediately discoverable on remote CCF

Test Case 6: Publish API after CAPIFs Interconnection with capifProvDoms not present

Test ID: interconnection-6

Description:

This test case validates that APIs published AFTER interconnection without explicit capifProvDoms configuration are still discoverable on the remote CCF through the established interconnection.

Pre-Conditions:

• Interconnection between CCF-A and CCF-B is already established
• Provider is pre-authorised at CCF-A
• API Invoker is pre-authorised at CCF-B

Execution Steps:

1. Get CCF-A identifier
2. Establish interconnection between CCF-A and CCF-B
3. Register Provider at CCF-A
4. Publish a shareable Service API at CCF-A (without capifProvDoms configuration)
5. Register and onboard Invoker at CCF-B
6. Discover published APIs at CCF-B

Information of Test:

1. Get CCF-A ID and Create Interconnection:

   • Get CCF-A identifier
   • Send POST https://{CAPIF_HOSTNAME}/helper/interconnection/request
   • body interconnection body with CCF-B hostname
   • Use SuperAdmin Certificate

2. Provider Registration at CCF-A:

   • Perform Provider Registration

3. Publish API without capifProvDoms:

   • Send POST https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis
   • body service api description with is_shareable=True
   • Use APF Certificate

4. Invoker Onboarding at CCF-B:

   • Perform Invoker Onboarding with parameters:
   • invoker_username: {INVOKER_USERNAME}_B
   • register_server: https://register-b:8184/
   • capif_server: https://capifcore-b:1443/

5. Discover APIs at CCF-B:

   • Send GET https://capifcore-b:1443/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id={aefIdFromCCFA}
   • Use {INVOKER_USERNAME}_B Certificate
   • Target server: https://capifcore-b:1443/

Expected Result:

1. Interconnection Creation:

   1. 201 Created response

2. API Publication:

   1. 201 Created response

3. API Discovery at CCF-B:

   1. 200 OK response
   2. Response body accomplishes DiscoveredAPIs data structure
   3. serviceAPIDescriptions array contains 1 entry
   4. pubApiPath.ccfIds is not empty
   5. pubApiPath.ccfIds contains CCF-A identifier

Test Case 7: Interconnection Request between CCF-A and CCF-B with one API published on CCF-B capifProvDoms not present

Test ID: interconnection-7

Description:

This test case validates that APIs published on CCF-B without capifProvDoms are discoverable from CCF-A after interconnection is established. The test also verifies that invokers on CCF-A can discover APIs published on CCF-B.

Pre-Conditions:

• Provider is pre-authorised at CCF-B
• API Invoker is pre-authorised at both CCF-A and CCF-B
• Interconnection between CCF-A and CCF-B is operational

Execution Steps:

1. Register Provider at CCF-B
2. Publish a shareable Service API at CCF-B (without capifProvDoms)
3. Get CCF-A identifier
4. Establish interconnection between CCF-A and CCF-B
5. Register and onboard Invoker at CCF-B
6. Discover published APIs at CCF-B
7. Register and onboard Invoker at CCF-A
8. Discover published APIs at CCF-A with aef-id filter from CCF-B provider

Information of Test:

1. Provider Registration at CCF-B:

   • Perform Provider Registration with parameters:
   • register_server: https://register-b:8184/
   • capif_server: https://capifcore-b:1443/
   • provider_username: {provider_username}_B

2. Publish API at CCF-B:

   • Send POST https://capifcore-b:1443/published-apis/v1/{apfId}/service-apis
   • body service api description with is_shareable=True
   • Use APF Certificate
   • Target server: https://capifcore-b:1443/

3. Get CCF-A ID and Create Interconnection:

   • Get CCF-A identifier
   • Send POST https://{CAPIF_HOSTNAME}/helper/interconnection/request
   • body interconnection body with CCF-B hostname
   • Use SuperAdmin Certificate

4. Invoker Onboarding at CCF-B:

   • Perform Invoker Onboarding with parameters:
   • invoker_username: {INVOKER_USERNAME}_B
   • register_server: https://register-b:8184/
   • capif_server: https://capifcore-b:1443/

5. Discover APIs at CCF-B:

   • Send GET https://capifcore-b:1443/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id={aefId}
   • Use {INVOKER_USERNAME}_B Certificate
   • Target server: https://capifcore-b:1443/

6. Invoker Onboarding at CCF-A:

   • Perform Invoker Onboarding

7. Discover APIs at CCF-A:

   • Send GET https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id={aefIdFromCCFB}
   • Use Invoker Certificate

Expected Result:

1. API Discovery at CCF-B:

   1. 200 OK response
   2. serviceAPIDescriptions array contains 1 entry

2. API Discovery at CCF-A:

   1. 200 OK response
   2. Response body accomplishes DiscoveredAPIs data structure
   3. serviceAPIDescriptions array contains 1 entry
   4. API from CCF-B is discoverable through interconnection

Test Case 8: Publish API at CCF_B after CAPIFs Interconnection with capifProvDoms not present

Test ID: interconnection-8

Description:

This test case validates that APIs published on CCF-B AFTER interconnection is established are accessible from CCF-A. Both local and remote invokers can discover APIs published on their respective CCFs.

Pre-Conditions:

• Interconnection between CCF-A and CCF-B is already established
• Provider is pre-authorised at CCF-B
• API Invoker is pre-authorised at both CCF-A and CCF-B

Execution Steps:

1. Get CCF-A identifier
2. Establish interconnection between CCF-A and CCF-B
3. Register Provider at CCF-B
4. Publish a shareable Service API at CCF-B (without capifProvDoms)
5. Register and onboard Invoker at CCF-B
6. Discover published APIs at CCF-B
7. Register and onboard Invoker at CCF-A
8. Discover published APIs at CCF-A with aef-id filter from CCF-B provider

Information of Test:

1. Get CCF-A ID and Create Interconnection:

   • Get CCF-A identifier
   • Send POST https://{CAPIF_HOSTNAME}/helper/interconnection/request
   • body interconnection body with CCF-B hostname
   • Use SuperAdmin Certificate

2. Provider Registration at CCF-B:

   • Perform Provider Registration with parameters:
   • register_server: https://register-b:8184/
   • capif_server: https://capifcore-b:1443/
   • provider_username: {provider_username}_B

3. Publish API at CCF-B:

   • Send POST https://capifcore-b:1443/published-apis/v1/{apfId}/service-apis
   • body service api description with is_shareable=True
   • Use APF Certificate
   • Target server: https://capifcore-b:1443/

4. Invoker Onboarding at CCF-B:

   • Perform Invoker Onboarding with parameters:
   • invoker_username: {INVOKER_USERNAME}_B
   • register_server: https://register-b:8184/
   • capif_server: https://capifcore-b:1443/

5. Discover APIs at CCF-B:

   • Send GET https://capifcore-b:1443/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id={aefId}
   • Use {INVOKER_USERNAME}_B Certificate
   • Target server: https://capifcore-b:1443/

6. Invoker Onboarding at CCF-A:

   • Perform Invoker Onboarding

7. Discover APIs at CCF-A:

   • Send GET https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id={aefIdFromCCFB}
   • Use Invoker Certificate

Expected Result:

1. Interconnection Creation:

   1. 201 Created response

2. API Discovery at CCF-B:

   1. 200 OK response
   2. serviceAPIDescriptions array contains 1 entry

3. API Discovery at CCF-A:

   1. 200 OK response
   2. Response body accomplishes DiscoveredAPIs data structure
   3. serviceAPIDescriptions array contains 1 entry
   4. pubApiPath is not empty
   5. API published after interconnection on CCF-B is discoverable from CCF-A

Test Case 9: Create a security context for an API invoker to access a published service API at other CCF (OAUTH)

Test ID: interconnection-9

Description:

This test case validates that an API invoker at CCF-A can create a security context to access an API published on CCF-B using OAUTH security method. The security context enables token-based access across CCF boundaries, and the JWT token issued by CCF-A is validated using CCF-B certificates.

Pre-Conditions:

• API Invoker is pre-authorised at CCF-A
• Provider is pre-authorised at CCF-B
• Interconnection between CCF-A and CCF-B is established
• CCF-B publishes an API with OAUTH as security method

Execution Steps:

1. Register Provider at CCF-B
2. Publish a shareable Service API at CCF-B with OAUTH security method
3. Establish interconnection between CCF-A and CCF-B
4. Register and onboard Invoker at CCF-A
5. Discover published APIs from CCF-B using Invoker at CCF-A
6. Create security context for the discovered API
7. Request access token for the service
8. Validate JWT token using CCF-A certificates (should fail)
9. Retrieve CCF-B certificates from vault
10. Validate JWT token using CCF-B certificates (should succeed)

Information of Test:

1. Provider Registration and API Publication at CCF-B:

   • Perform Provider Registration with parameters:
   • register_server: https://register-b:8184/
   • capif_server: https://capifcore-b:1443/
   • provider_username: {provider_username}_B
   • Publish Service API with:
   • is_shareable=True
   • security_methods=['OAUTH']
   • Send POST https://capifcore-b:1443/published-apis/v1/{apfId}/service-apis
   • Use APF Certificate
   • Target server: https://capifcore-b:1443/

2. Create Interconnection:

   • Send POST https://{CAPIF_HOSTNAME}/helper/interconnection/request
   • body interconnection body with CCF-B hostname
   • Use SuperAdmin Certificate

3. Invoker Onboarding at CCF-A:

   • Perform Invoker Onboarding

4. Discover APIs from CCF-B:

   • Send GET https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id={aefIdFromCCFB}
   • Use Invoker Certificate

5. Create Service Security Context:

   • Extract API information from discovery response
   • Send PUT https://{CAPIF_HOSTNAME}/capif-security/v1/trustedInvokers/{apiInvokerId}
   • body service security body from discovered response
   • Use Invoker Certificate

6. Request Access Token:

   • Get service name and aef-id from security context
   • Create scope: 3gpp#{aefId}:{serviceName}
   • Send POST https://{CAPIF_HOSTNAME}/capif-security/v1/securities/{apiInvokerId}/token
   • body access token req body with scope
   • Use Invoker Certificate

7. Validate JWT Token with CCF-A Certificates:

   • Validate JWT token signature using {CCF_USERNAME}.crt
   • Expected: Token validation should fail or return None (invalid)

8. Retrieve CCF-B Certificates from Vault:

   • Retrieve CCF-B certificates: {CCF_USERNAME}_B.crt
   • capif_url: https://capifcore-b:1443/
   • vault_url: {CAPIF_HTTP_VAULT_URL}
   • Use SuperAdmin Certificate

9. Validate JWT Token with CCF-B Certificates:

   • Validate JWT token signature using {CCF_USERNAME}_B.crt
   • Expected: Token validation should succeed

Expected Result:

1. API Publication at CCF-B:

   1. 201 Created response
   2. Response body accomplishes ServiceAPIDescription data structure

2. Interconnection Creation:

   1. 201 Created response

3. API Discovery at CCF-A:

   1. 200 OK response
   2. Response body accomplishes DiscoveredAPIs data structure
   3. serviceAPIDescriptions array contains 1 entry from CCF-B

4. Security Context Creation:

   1. 201 Created response
   2. Response body accomplishes ServiceSecurity data structure
   3. Location Header contains resource URL for the context

5. Access Token Request:

   1. 200 OK response
   2. Response body accomplishes AccessTokenRsp data structure with:
      • token_type: "Bearer"
      • access_token: Non-empty JWT token

6. JWT Token Validation with CCF-A Certs:

   1. Validation fails (token was issued by CCF-B, not signed with CCF-A cert)

7. JWT Token Validation with CCF-B Certs:

   1. Validation succeeds
   2. Payload is not empty
   3. Token is valid and can be used to access CCF-B services

Test Case 10: Create a security context for an API invoker to access a published service API at other CCF (PKI)

Test ID: interconnection-10

Description:

This test case validates that an API invoker at CCF-A can create a security context to access an API published on CCF-B using PKI security method. The security context includes certificate-based authentication details, and the AEF at CCF-B can retrieve the security context including CA root certificate for PKI validation.

Pre-Conditions:

• API Invoker is pre-authorised at CCF-A
• Provider is pre-authorised at CCF-B
• Interconnection between CCF-A and CCF-B is established
• CCF-B publishes an API with PKI as security method

Execution Steps:

1. Register Provider at CCF-B
2. Publish a shareable Service API at CCF-B with PKI security method
3. Establish interconnection between CCF-A and CCF-B
4. Register and onboard Invoker at CCF-A
5. Discover published APIs from CCF-B
6. Create security context for the discovered API
7. AEF at CCF-B retrieves the security context with authentication info
8. Retrieve CCF-B certificates from vault
9. Verify security context contains CA root certificate in authenticationInfo
10. Verify security context does NOT contain authorizationInfo (only PKI)

Information of Test:

1. Provider Registration and API Publication at CCF-B:

   • Perform Provider Registration with parameters:
   • register_server: https://register-b:8184/
   • capif_server: https://capifcore-b:1443/
   • provider_username: {provider_username}_B
   • Publish Service API with:
   • is_shareable=True
   • security_methods=['PKI']
   • Send POST https://capifcore-b:1443/published-apis/v1/{apfId}/service-apis
   • Use APF Certificate

2. Create Interconnection:

   • Send POST https://{CAPIF_HOSTNAME}/helper/interconnection/request
   • body interconnection body with CCF-B hostname
   • Use SuperAdmin Certificate

3. Invoker Onboarding at CCF-A:

   • Perform Invoker Onboarding

4. Discover APIs from CCF-B:

   • Send GET https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id={aefIdFromCCFB}
   • Use Invoker Certificate

5. Create Service Security Context:

   • Send PUT https://{CAPIF_HOSTNAME}/capif-security/v1/trustedInvokers/{apiInvokerId}
   • body service security body from discovered response
   • Use Invoker Certificate

6. AEF retrieves Security Context from CCF-B:

   • Send GET https://capifcore-b:1443/capif-security/v1/trustedInvokers/{apiInvokerId}?authenticationInfo=true&authorizationInfo=true
   • Use AEF Certificate (from CCF-B provider)
   • Target server: https://capifcore-b:1443/

7. Retrieve CCF-B Certificates from Vault:

   • Retrieve certificates with {CCF_USERNAME}_B
   • capif_url: https://capifcore-b:1443/
   • vault_url: {CAPIF_HTTP_VAULT_URL}
   • Use SuperAdmin Certificate

8. Read CA Root Certificate:

   • Read ca.crt file

9. Verify Security Context Structure:

   • Compare retrieved security context with expected structure
   • Verify securityInfo[0].authenticationInfo contains CA root certificate
   • Verify securityInfo[0].selSecurityMethod is PKI

Expected Result:

1. API Publication at CCF-B:

   1. 201 Created response
   2. Response body accomplishes ServiceAPIDescription data structure

2. Interconnection Creation:

   1. 201 Created response

3. API Discovery at CCF-A:

   1. 200 OK response
   2. serviceAPIDescriptions array contains 1 entry

4. Security Context Creation:

   1. 201 Created response
   2. Response body accomplishes ServiceSecurity data structure
   3. Location Header contains resource URL

5. Security Context Retrieval at CCF-B:

   1. 200 OK response
   2. Response body accomplishes ServiceSecurity data structure
   3. securityInfo array contains 1 entry
   4. securityInfo[0].authenticationInfo contains CA root certificate content
   5. securityInfo[0].selSecurityMethod equals PKI
   6. Security context structure matches expected format with PKI authentication details

Test Case 11: Create a security context for an API invoker to access a published service API at other CCF (PSK)

Test ID: interconnection-11

Description:

This test case validates that an API invoker at CCF-A can create a security context to access an API published on CCF-B using PSK (Pre-Shared Key) security method. The security context enables PSK-based authentication, and verification confirms both authentication and authorization information is present in the security context.

Pre-Conditions:

• API Invoker is pre-authorised at CCF-A
• Provider is pre-authorised at CCF-B
• Interconnection between CCF-A and CCF-B is established
• CCF-B publishes an API with PSK as security method

Execution Steps:

1. Register Provider at CCF-B
2. Publish a shareable Service API at CCF-B with PSK security method
3. Establish interconnection between CCF-A and CCF-B
4. Register and onboard Invoker at CCF-A
5. Discover published APIs from CCF-B
6. Create security context for the discovered API
7. AEF at CCF-B retrieves the security context with authentication and authorization info
8. Retrieve CCF-B certificates from vault
9. Verify security context contains both authenticationInfo and authorizationInfo

Information of Test:

1. Provider Registration and API Publication at CCF-B:

   • Perform Provider Registration with parameters:
   • register_server: https://register-b:8184/
   • capif_server: https://capifcore-b:1443/
   • provider_username: {provider_username}_B
   • Publish Service API with:
   • is_shareable=True
   • security_methods=['PSK']
   • Send POST https://capifcore-b:1443/published-apis/v1/{apfId}/service-apis
   • Use APF Certificate

2. Create Interconnection:

   • Send POST https://{CAPIF_HOSTNAME}/helper/interconnection/request
   • body interconnection body with CCF-B hostname
   • Use SuperAdmin Certificate

3. Invoker Onboarding at CCF-A:

   • Perform Invoker Onboarding

4. Discover APIs from CCF-B:

   • Send GET https://{CAPIF_HOSTNAME}/service-apis/v1/allServiceAPIs?api-invoker-id={apiInvokerId}&aef-id={aefIdFromCCFB}
   • Use Invoker Certificate

5. Create Service Security Context:

   • Send PUT https://{CAPIF_HOSTNAME}/capif-security/v1/trustedInvokers/{apiInvokerId}
   • body service security body from discovered response
   • Use Invoker Certificate

6. AEF retrieves Security Context from CCF-B:

   • Send GET https://capifcore-b:1443/capif-security/v1/trustedInvokers/{apiInvokerId}?authenticationInfo=true&authorizationInfo=true
   • Use AEF Certificate (from CCF-B provider)
   • Target server: https://capifcore-b:1443/

7. Retrieve CCF-B Certificates from Vault:

   • Retrieve certificates with {CCF_USERNAME}_B
   • capif_url: https://capifcore-b:1443/
   • vault_url: {CAPIF_HTTP_VAULT_URL}
   • Use SuperAdmin Certificate

8. Verify Security Context Structure:

   • Verify securityInfo[0].authenticationInfo is not empty (contains PSK credentials)
   • Verify securityInfo[0].authorizationInfo is not empty (contains authorization policies)

Expected Result:

1. API Publication at CCF-B:

   1. 201 Created response
   2. Response body accomplishes ServiceAPIDescription data structure

2. Interconnection Creation:

   1. 201 Created response

3. API Discovery at CCF-A:

   1. 200 OK response
   2. serviceAPIDescriptions array contains 1 entry

4. Security Context Creation:

   1. 201 Created response
   2. Response body accomplishes ServiceSecurity data structure

5. Security Context Retrieval at CCF-B:

   1. 200 OK response
   2. Response body accomplishes ServiceSecurity data structure
   3. securityInfo[0].authenticationInfo is not empty
   4. securityInfo[0].authorizationInfo is not empty
   5. Both authentication credentials and authorization policies are present for PSK security method