Namespace Lifecycle and Decommissioning

[ikethecoder]

Description: This is an Epic that covers the expected behaviour for deletion of Gateway Configuration, Product Environments, Authorization Profiles and Namespaces.

Authorization Profiles: Only delete if there are no Environments associated with the Authorization Profile. Provide an error message indicating which Product/Environments must be updated before the profile can be deleted. Similar logic for the Client Registration details on the Authorization Profile. ALTERNATE: A deleted environment config could result in related Environments to be made "inactive" and before deleting the Authorization Profile, update related Environments to "inactive" as they will now have incomplete configuration. Only allow the deletion if the Environments have no associated Service Access records.

Product: Only delete if there are no Environments with associated Service Access records. Will cascade delete all Environments if these rules pass.

Environment: Will delete the environment if there are no associated Service Access records. If there are existing records, then a confirmation message will be presented to say: "There are X Consumers that will have their access revoked, are you sure you want to continue?". By accepting, a "force" deletion will happen where it will Revoke Access for each related Consumer.

Namespace: Will delete the namespace if Environments are safe to delete (see above rules) and there is no Gateway Configuration for the namespace. If there exists either, then a confirmation message will be presented to say: "There are X Consumers that will have their access revoked, and there are 4 routes that will be deleted, are you sure you want to continue?". By accepting, a "force" deletion will happen where it will Revoke Access for each related Consumer and delete all the Gateway Configuration for the Namespace. The Namespace will be removed from the Keycloak Group and the Authorization Services. Related Authorization Profiles, Documentation and Service Accounts will also be deleted. An Activity record will be created to capture the action.

• Question: Should a namespace name be reusable? If not, then keep the Keycloak Group and add an attribute of "decommissioned".
• Recommendation: Namespace names should NOT be reusable. The Activity records will live forever and users with "Namespace.Assign" (or Namespace.Audit?) will be able to view the Activity for the relevant namespaces.

Implement v2 of the Directory API:

• Add GET and DELETE for Namespace, Product/Environment, Authorization Profile, Content, Dataset
• Cascade revocation of access of all Environment related Consumer access
• Add ability to DELETE Namespace with cascading revocation of access and removal of Gateway Services
• Add ability in the API to query the Activity details
• Record details of revoked access in Activity
• Add support for using your Portal credentials to interact with the API
• Update the GWA CLI to support the additional capabilities of v2 of the Directory API
• Add descriptions for Operations in OpenAPI spec for v2
• Add example in OpenAPI spec for v2
• Add enumerators for relevant Schemas in the OpenAPI spec for v2
• Fix issue of orphaned Service Access records due to deletion/reassignment of Environments
• Include work from the Hierarchical Access Control Epic into v2 of the Directory API
• UI updates for Delete Namespace and Delete Environment to show messaging for the warning, impact and confirmation
• UI updates for Delete Authorization Profile and Delete Product to block deletion based on above requirements
• Protect v2 of the API using a Kong plugin (oidc or jwt-keycloak)
• Improve unit test coverage (currently only 12%)
• For namespace deletion, include the removal of Service/Routes by calling the gwa-api
• Update the gwa-api to provide the "default" permissions for namespaces

[JohnathanBrammall]

Warning messages for deletion need to be completed for UI/UX. Using the API must set deletion to 'Force' to complete.
Existing Service Accounts, Gateway Configuration, Users. - currently appear together in one message from the error message.