What is the process for requesting configuration changes to Auth Central?

[alukach]

In the event that a developer needs an alteration to the available Clients, Groups or Scopes, how should they go about making that request?

I’m not exactly sure how something like Auth Central would compare to what exists currently.

For things like configuration of applications, I believe all of VEDA subscribes to an “Infrastructure as Code” pattern when the deployment and configuration of services is stored with Github and deployed via Github actions. This makes it very easy and transparent for anyone to suggest and discuss alterations to current configuration, while requiring approval before making its way to production.

For things like data within applications, I believe that is typically provided via ingestion pipelines that submit data to a DB (either directly via DB connection or indirectly via REST API).

So how does something like Clients, Groups, and Scopes fit in with this? It feels like there are two paths forward:

1. Configuration as Code: If we treat this as configuration that is stored within code, then a developer could make a PR, have it be approved, and a CICD pipeline would make that true on production. We did this a bit with an Auth Central predecessor, veda-auth (link) which uses AWS Cognito. To follow a similar pattern, there is a Terraform provider for KeyCloak (link). In this case, the management of Clients, Groups, Scopes could be self-managed via developers through Gtihub, while something like the associating of Users to Groups could be managed via admins through the Auth Central Admin.
2. Configuration as Data: If we treat this as data stored in a database, we would rely on admin members to make API requests or take actions through the Auth Central Admin. We could still loop Github into the flow as a change management system, wherein a developer would create an issue describing the request and an admin could discuss and enact the request on behalf of the developer (Github’s Issue Forms are currently in beta but could be useful in the process, link).

I think the Configuration as Data approach is probably more easily achieved and more in line with what has already been envisioned for Auth Central.

[DImuthuUpe]

Configuration as code would be ideal if we do not have a centralized place to manage and see that information. On the other hand, if we enable visibility and configuration through centralized Auth Central portal, what would we lose?

[DImuthuUpe]