keratin
Web GUI
Hello @cainlevy
It is very good that you continue to develop the project :+1:
Did you think about a web GUI for the project?
Hi @egorsmkv --
A web GUI could be fun! I think it could visualize the active account stats and provide a browse-and-click interface for all of the administrative functions (lock, unlock, archive, expire).
I would approach a GUI as a separate frontend repository, then add any missing API methods to the AuthN backend.
@cainlevy,
Any requirements you'd like to see for this? I may start some work on the GUI as I get time. Are you against any frontend frameworks? I personally am a big supporter of Vue.js and would prefer to use that, maybe even Nuxt for SSR due to the secure nature of something like this.
Originally I was thinking about this as an API client for administrative functions, but now I wonder if that's feasible for deployments where the admin endpoints are firewalled away from public traffic.
Ideas?
Should this:
- Assume publicly accessible admin endpoints
- Require deployments to enable inbound traffic to admin endpoitns from safe IPs
- Interact with a service running behind the firewall that integrates the AuthN API
- _____________________?
I'll hit these one-by-one. These are opinion.
Assume publicly accessible admin endpoints
Nope. I think it should be accessible from whatever computer running the UI, but not necessarily assume the endpoints to be public.
Require deployments to enable inbound traffic to admin endpoitns from safe IPs
No, I think it is totally possible for endpoints to be accessible to the admin and the admin only, for example with Kubernetes you can do port-forward to services from your local machine but not have the service be public.
Interact with a service running behind the firewall that integrates the AuthN API
I think how this interacts with the admin API should be up to the deployer, not Authn. I see this as a GUI that can be ran locally, for example authn-ui serve --api-server http://localhost:8000/admin, and not something that is long-running. This allows Authn to stand behind the idea of keeping the admin API endpoints internal and internal only. The deployer should know how to access their internal admin API. If they wanted to publicly expose their UI they could, but I don't see that as a best practice.
I'm okay with all of that. So this is intended to provide convenience in local environments. If someone wants to use it in production, it's on them to figure out a network path.
Given that, I'd rather encourage experimentation than create artificial constraints. Do you anticipate needing any extra APIs from AuthN? There's no way to fetch a list of accounts, for example. 🤔
I do see the need for additional APIs, especially the ability to list users. Without knowing the features we want to implement, I can't tell you every API endpoint. However, I can say that where where there is a CUD, we need an R (from CRUD). I think this is mostly the case, though.
How about OAuth identities? I'm expecting to add that data to the GET /accounts/:id response at some point, but don't have any plans for admin CUD mutations.
Oh, and this would also likely motivate maintaining the REST interface even when gRPC is stable.
I don't really see a benefit in moving OAuth identities to the database or making them accessible via CUD mutations, however, I see some value in maybe helping them generate the necessary environment variables using a point-and-click configuration screen. It would need to be made obvious that the settings are not persisted, but allowing the env variables to be exported as .env, for docker run, or even Kubernetes secrets might be helpful for those just getting started.
Just as a follow up, are there plans to implement an API endpoint to list all users?
Yes, I'm expecting it. Would you open another issue where we can spec and track it?