MED-2516 Change Cloud Entity to Cloudentity, replace Authorized Contr…

…ol Plane … (#55)

* Change Cloud Entity to Cloudentity, replace Authorized Control Plane with Cloudentity

* 37 Markdown errors that previously bypassed markdown linter

* ACP > Cloudentity

* review edits

content/en/docs/Configuration/Certificate Management/jwks.md

@@ -18,19 +18,19 @@ The ASPSP (Account Servicing Payment Service Provider, the bank or similar insti
 
 Follow this procedure to change the signing certificate with the appropriate values:
 
-1. Connect to the ACP Server and check the current authorization server signing certificate.
+1. Connect to the Cloudentity server and check the current authorization server signing certificate.
 
-   * Replace `<ACP server interface`> by your ACP server interface, and then connect to the following URL in your navigator:
-      `https://<ACP server interface>/app/default/admin/openbanking_brasil/workspaces/signing-keys`.
+   * Replace `<Cloudentity server interface`> by your Cloudentity server interface, and then connect to the following URL in your navigator:
+      `https://<Cloudentity server interface>/app/default/admin/openbanking_brasil/workspaces/signing-keys`.
    * Connect with your user/admin password.
    * Verify that the **Current key in use** is the default ASPSP signing certificate (what you will change with this procedure).
 
-    ![ACPSigningKey](/Images/ACPSigningKey.PNG)
+    ![CloudentitySigningKey](/Images/ACPSigningKey.PNG)
 
-2. Export the actual authorization server configuration with ACP API.
-   * Navigate to the ACP swagger page. The previous step will keep you logged in with your credentials.
+2. Export the actual authorization server configuration with Cloudentity API.
+   * Navigate to the Cloudentity swagger page. The previous step will keep you logged in with your credentials.
    Browse to the servers section, and then *Get authorization server*.</br>
-   `https://<ACP server interface>/api/swagger/default/openbanking_brasil/#/servers/getAuthorizationServer`.
+   `https://<Cloudentity server interface>/api/swagger/default/openbanking_brasil/#/servers/getAuthorizationServer`.
    * Click *Try it out*.
    * Replace with your tid (tenant id) and aid (authorization server id). In Open Banking Brasil, the tid is *default* and the aid is *openbanking_brasil*
    * Execute the request.
@@ -45,19 +45,19 @@ Follow this procedure to change the signing certificate with the appropriate val
 
 5. Upload the configuration to the authorization server.
    * Go back to the swagger page, to the *Update authorization server* section.
-      `https://<ACP server interface>/api/swagger/default/openbanking_brasil/#/servers/updateAuthorizationServer`.
+      `https://<Cloudentity server interface>/api/swagger/default/openbanking_brasil/#/servers/updateAuthorizationServer`.
    * Click *Try it out*.
    * Replace with your tid (tenant id) and aid (authorization server id). In Open Banking Brasil, the tid is *default* and the aid is *openbanking_brasil*.
    * Paste the response of the previous step 3 with the new signing certificate in the body.
    * Execute the request.
    ![PutAuthServer](/Images/PutAuthServer.PNG)
 
 6. Validate the procedure.
-   * Refresh the ACP interface and you will see that your ASPSP signature key has been modified.
+   * Refresh the Cloudentity interface and you will see that your ASPSP signature key has been modified.
 
 ## TPP signing certificate
 
-The TPP (Third Party Provider) signing certificates are located in the ACP configuration. Connect to the ACP Interface, navigate to your workspace (openbanking Brasil for Brasil specifications), and then click on the application. Click the application name of the desired TPP.
+The TPP (Third Party Provider) signing certificates are located in the Cloudentity configuration. Connect to the Cloudentity Interface, navigate to your workspace (openbanking Brasil for Brasil specifications), and then click on the application. Click the application name of the desired TPP.
 The signing certificate is located in the OAuth tab, under client authentication, as a JSON Web Key Set. You can modify the signing certificate here, and then click *Save changes*.
 
 ![TPPSignatureKey](/Images/TPPSignatureKey.PNG)

content/en/docs/Configuration/Certificate Management/mtls.md

@@ -11,7 +11,7 @@ How to change and test the certificate configurations required for Mutual Authen
 
 Mutual authentication is required for most APIs developed for Open Banking.
 
-According to the Open Banking Specification, Mutual Transport Layer Security (MTLS) client connections are required for the Cloud Entity and API Gateway Listener components. See the diagram for details on MTLS setup.
+According to the Open Banking Specification, Mutual Transport Layer Security (MTLS) client connections are required for the Cloudentity and API Gateway Listener components. See the diagram for details on MTLS setup.
 ![MTLS diagram](/Images/MTLS.svg)
 
 See more about the Certificate Verification with MTLS in Open Banking context in [Mutual Authentication and Certificate Verification](/docs/overview/integration/mutual-auth).
@@ -30,9 +30,9 @@ Refer to the required features of the ingress controller in [Deployment - Prereq
 
 {{% alert title="Note" color="primary" %}} Usage of the MTLS Listener embedded on the API-gateway configuration would require each customer to build their own Docker images, as the container maturity level does not allow us to externalize certificates.{{% /alert %}}
 
-### Cloud Entity MTLS
+### Cloudentity MTLS
 
-Cloud Entity supports the MTLS and the root CA must be added in the component.
+Cloudentity supports the MTLS and the root CA must be added in the component.
 
 ## Setup the solution for MTLS with test certificates
 
@@ -41,7 +41,7 @@ This section includes the prerequisites and tasks to setup the solution for MTLS
 ### Prerequisites
 
 * An openssl tool available.
-* An ACP deployed on Kubernetes.
+* A Cloudentity deployed on Kubernetes.
 * An APIM component deployed on Kubernetes.
 * Nginx Ingress Controller deployed on Kubernetes.
 
@@ -142,16 +142,16 @@ openssl req -new -newkey rsa:2048 -nodes -out tpp1.csr -keyout tpp1.key
 
 ### Deploy root CA certificates on the Open Banking platform
 
-#### ACP
+#### Cloudentity
 
-Connect to the Cloud Entity admin page on `https://acp.<domain-name>/app/default/admin/`.
+Connect to the Cloudentity admin page on `https://Cloudentity.<domain-name>/app/default/admin/`.
 
 1. Select workspace **openbanking_brasil**.
 2. Click **Settings** on the left panel.
-![ACP Authorization Settings](/Images/mtls-acp-auth.png)
+![Cloudentity Authorization Settings](/Images/mtls-acp-auth.png)
 3. Click **Authorization** on the main frame.
 4. Scroll down to **Trusted client certificates**.
-![ACP Trusted client certificates ](/Images/mtls-acp-ca.png)
+![Cloudentity Trusted client certificates ](/Images/mtls-acp-ca.png)
 5. Paste ca1.crt and ca2.crt contents in the text box.
 6. Click **Save**.
 
@@ -194,20 +194,20 @@ kubectl get pods -n <nginx namespace>
 
 Here are several scenarios you can use to test the MTLS setup with NGINX and APIM:
 
-* Configure both CA1 and CA2 in NGINX, APIM, and ACP as described in the previous section.
+* Configure both CA1 and CA2 in NGINX, APIM, and Cloudentity as described in the previous section.
     * Use a simple curl command to test a call without cert and keys.
         * `curl 'https://mtls-api-proxy.<domain-name>/healthcheck'`
         * The call should return 400 with a SSL certificate error
     * Use a simple curl command to test sending the cert and key for TPP1 and TPP2.
         * `curl 'https://mtls-api-proxy.<domain-name>/healthcheck' --cert tpp1.crt --key tpp1.key`
         * `curl 'https://mtls-api-proxy.<domain-name>/healthcheck' --cert tpp2.crt --key tpp2.key`
         * The call should return 200 with status ok
-* Configure only CA1 in NGINX, APIM, and ACP as described in the previous section.
+* Configure only CA1 in NGINX, APIM, and Cloudentity as described in the previous section.
     * Use a simple curl command to test sending the cert and key for TPP2.
         * `curl 'https://mtls-api-proxy.<domain-name>/healthcheck' --cert tpp2.crt --key tpp2.key`
         * The call should return 400 with a SSL certificate error
 
-You can do similar tests on ACP using the following curl command:
+You can do similar tests on Cloudentity using the following curl command:
 
 ```bash
 curl --request POST 'https://acp.<domain-name>/default/openbanking_brasil/oauth2/token' \

content/en/docs/Configuration/api-management.md

@@ -29,7 +29,7 @@ This configuration can be read at the beginning of any policy using a common pol
 
 In FDX deployment, by default, there is at least one row for each API and a row with generic information which is applicable to all APIs.
 
-In Open Finance Brazil deployment, by default, only one line exists with no criteria (columns b to e) and values (column k) corresponding to solution deployment parameters. 
+In Open Finance Brazil deployment, by default, only one line exists with no criteria (columns b to e) and values (column k) corresponding to solution deployment parameters.
 
 Refer to [Solution Deployment](/docs/deployment/installation) to see how to change these values during deployment.
 
@@ -41,34 +41,34 @@ Click on configuration and the line to be checked or updated.
 
 ![kps-values](/Images/api-gateway-manager-kps-values.png)
 
-Several values should correspond to the settings of Cloudentity ACP or its consent module. See the below mapping table to check that the KPS values are correct.
+Several values should correspond to the settings of Cloudentity or its consent module. See the below mapping table to check that the KPS values are correct.
 
 #### Mapping table for FDX
 
-| KPS Values | How to retrieve or check this values in ACP UI |
+| KPS Values | How to retrieve or check this values in Cloudentity UI |
 | --- | --- |
-| oauth_ce_host | hostname of acp server |
-| oauth_ce_port | port of acp server |
-| oauth_ce_tenantid | tenant id in ACP server |
-| oauth_ce_id | workspace id in ACP where client applications are created and consents are stored |
+| oauth_ce_host | hostname of Cloudentity server |
+| oauth_ce_port | port of Cloudentity server |
+| oauth_ce_tenantid | tenant id in Cloudentity server |
+| oauth_ce_id | workspace id in Cloudentity where client applications are created and consents are stored |
 | oauth_introspect_client_id | client id of app named "bank" in FDX workspace |
 | oauth_ce_idp_clientId | client id of the custom IdP configured in FDX workspace |
 | oauth_ce_idp_clientSecret | client secret of the custom IdP configured in FDX workspace |
 | oauth_consent_user_clientSecret | client secret of the custom IdP configured in bank-customers workspace |
 
 #### Mapping table for Open Finance Brazil
 
-| KPS Values | How to retrieve or check this values in ACP UI |
+| KPS Values | How to retrieve or check this values in Cloudentity UI |
 | --- | --- |
 | oauth_consent_clientId | Custom IDP Demo bank login ID: bank customer. |
 | oauth_consent_clientSecret | Custom IDP Demo bank login secret: bank customer. |
 | oauth_consent_confirmation_clientid | Settings: consent screen client id. |
 | oauth_consent_confirmation_clientSecret | Settings: consent screen client secret. |
 | oauth_consent_user_clientSecret | Custom IDP Demo bank login secret: open banking workspace. |
-| oauth_host | Host of acp server. |
-| oauth_id | Openbanking workspace id in ACP server. |
+| oauth_host | Host of Cloudentity server. |
+| oauth_id | Openbanking workspace id in Cloudentity server. |
 | oauth_introspect_clientid | App is bank in openbanking workspace. |
-| oauth_tenantid | Tenant id in ACP server. |
+| oauth_tenantid | Tenant id in Cloudentity server. |
 
 ### API policies
 

content/en/docs/Overview/Integration/Financial-Data-Exchange-Integration/_index.md

@@ -20,13 +20,16 @@ All APIs that provide access to data are implemented in the same manner. The con
 ![FDX Wrokflow](/Images/FDX_Workflow.png)
 
 ### Steps
+
 Step 1: Request Account Information
+
 * This flow begins with a End User consenting to allow a DR to access account information data.
 
 Step 2: DR initiates a POST request to Data Providers’s (DP) POST /par endpoint using the Pushed Authorization Request (PAR) method
+
 * the authorization_details request parameter MUST contain a JSON-formatted object with two members in compliance with the RAR format specified by [RAR memo, § 2](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar#section-2)
-  * the type parameter with value fdx_v1.0, and
-  * a consentRequest parameter containing a valid ConsentRequest entity; For example:
+    * the type parameter with value fdx_v1.0, and
+    * a consentRequest parameter containing a valid ConsentRequest entity; For example:
 
   ```bash
   {
@@ -54,9 +57,9 @@ Step 2: DR initiates a POST request to Data Providers’s (DP) POST /par endpoin
 
 * DR must be authenticated with methods allowed by the FDX security profile
 * If successful, DP responds with a 201 Created HTTP response code and JSON response
-  * endpoint behavior and responses defined in detail by [PAR memo, § 2](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-par#section-2)
+    * endpoint behavior and responses defined in detail by [PAR memo, § 2](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-par#section-2)
 * DR uses the returned request_uri to build its subsequent request to GET /authorize
-  * endpoint behavior and responses defined in detail by [PAR memo, § 4](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-par#section-4)
+    * endpoint behavior and responses defined in detail by [PAR memo, § 4](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-par#section-4)
 
 Step 3: User authentication, consent and authorization
 
@@ -72,4 +75,5 @@ Step 4: Request Data
 * The unique AccountId(s) that are valid for the account-access-consent will be returned with a call to GET /accounts. This will always be the first call once an DR has a valid access token.
 
 ### Sequence Diagram
+
 ![FDX End-to-end web journey sequence](/Images/FDX_Web_Journey_Sequence.svg)

content/en/docs/Overview/Integration/_index.md

@@ -27,6 +27,6 @@ Refer to the table for an explanation of each labeled arrow in the diagram.
 |  10 | The API Gateway and integration applications retrieves data from the appropriate data source. This can either be from Core Banking Applications or Mock Data provided with the Amplify Open Banking solution. |
 |  11 | The events are logged to the Amplify Platform for Analytics. |
 
-The sections below expand on this through several more detailed sequence-based views. 
+The sections below expand on this through several more detailed sequence-based views.
 
 Note these sequence diagrams **focus largely on the happy path** and do not show specific error flows for the sake of brevity.