@@ -115,35 +115,37 @@ Peers are aligned before the local write:
Peer copies are found by old apiName, because each peer assigns its own apiId. If any peer cannot be aligned, the local API is left unchanged.
In case of a DELETE request:
**In case of a DELETE request:**
Unpublish from peers first, then delete locally. If a peer is unreachable, the local copy stays so the two CCFs do not drift.
### Creation of Security Context by invoker onboarded on different CCF than Provider
### Creation of Security Context
From the point of view of Invoker and Providers, the access to exposed APIs follow the same flows for one CCF, this means:
1. Provider will Register itself and publish APIs to their own CCF.
2. Invoker will onboard and discover APIs to their own CCF.
3. Invoker request creation of security context of any of APIs discovered.
1. Provider will Register itself and publish APIs to its own CCF.
2. Invoker will onboard and discover APIs to its own CCF.
3. Invoker request creation of a security context for any of APIs discovered to its own CCF.
From the point of view of all entities, the interaction will be the same, but when the Provider and Invoker are in differen CCFs, internally the flows change.
From the point of view of all entities, the interaction will be the same, but when the Provider and Invoker are in differen CCFs, internally the flows change. The internal flow will be explained below.
When Invoker request creation of Security Context to an API registered on interconnected CCF, then Invoker's CCF will request creation of security context con Provider's CCF. This will trigger creation of ACLs and some other events related.
After creation there will be 3 different flow involved depending on selSecurityMethod returned by Invoker's CCF:
On next section the flows involved depending on security method selected will be detailed.
### Consume Provider's API
* OAUTH: Access token will be used to access exposed API.
* PKI: Invoker must use their certificate to access exposed API.
* PSK: Invoker must derive they PSK key from connexion between invoker and CCF.
Previous section created the security context to allow communicaction from Invoker and Provider's API. There will be 3 different flow involved depending on **selSecurityMethod** returned by Invoker's CCF:
NOTE: PSK and PKI security methods imply Provider must implement AEF_security_API defined by 3GPP, because Invoker will begin the communication to exposed api by requesting POST to /check-authentication with [body](./check-authentication.json).
***OAUTH**: Access token will be used to access exposed API.
***PKI**: Invoker must use its certificate to access exposed API.
***PSK**: Invoker must derive the PSK key from connexion between invoker and CCF at context creation.
*NOTE: PSK and PKI security methods imply Provider must implement AEF_security_API defined by 3GPP, because Invoker will begin the communication to exposed api by requesting POST to /check-authentication with [body](./check-authentication.json).*
We will see each security method flow in next sections.
In this scenario, Invoker's CCF acts as a gateway to forward request to Provider's CCF, because this token will be created by private certificate of Provider's CCF.
@@ -165,7 +167,7 @@ In this scenario, Invoker's CCF acts as a gateway to forward request to Provider
For PKI security method,
* Provider must implement AEF_Security_API, defined by 3GPP. The check-authentication endpoint must be requested from Invoker before initiate consumption of exposed API, indicating api_invoker_id.
* Provider must implement *AEF_Security_API*, defined by 3GPP. The *check-authentication* endpoint must be requested from Invoker before initiate consumption of exposed API, indicating api_invoker_id.[body](./check-authentication.json)
* Provider will request security context of api_invoker_id to Provider's CCF, and Provider's CCF will request security context to Invoker's CCF and this security context will be forwarded to Provider, which includes the ca root to decode invoker's certificate.
* Provider will take authenticationInfo present at security_info array inside GET security context response and store it to be used later.
* Invoker reach exposed API by including its certificate.
In this scenario, Provider must implement *AEF_Security_API* in order to begin communication by reach *check-authentication* by Invoker previous start consuming Provider's API.
Provider will request on this initial step the Security Context involved to obtain CA to be used to validate Invoker's certificate.
#### PSK
For PSK security method,
* Invoker derived PSK when request creation of Security Context and store it to be used later.
* Provider must implement AEF_Security_API, defined by 3GPP. The check-authentication endpoint must be requested from Invoker before initiate consumption of exposed API, indicating api_invoker_id.
* Provider must implement *AEF_Security_API*, defined by 3GPP. The *check-authentication* endpoint must be requested from Invoker before initiate consumption of exposed API, indicating api_invoker_id.[body](./check-authentication.json)
* Provider will request security context of api_invoker_id to Provider's CCF, and Provider's CCF will request security context to Invoker's CCF and this security context will be forwarded to Provider, which includes the ca root to decode invoker's certificate and PSK derived by Invoker's CCF.
* Provider will take authenticationInfo, and authorizationInfo present at security_info array inside GET security context response and store them to be used later.
* Invoker reach exposed API including PSK inside Authorization header.
In this scenario, Provider must implement *AEF_Security_API* in order to begin communication by reach *check-authentication* by Invoker previous start consuming Provider's API.
Provider will request on this initial step the Security Context involved to obtain CA and PSK to be used to validate Invoker's communication.
