WebUI - admin interface beginnings

[yaleman]

As a user with admin privileges, I'd like to be able to look at the details of other users in the Web UI.

Describe the solution you'd like

• [x] add an "admin" link in the nav
• [x] present a list of options (accounts, groups, feral crab management, oauth2 integrations)
• [x] when clicking on "accounts", be prompted with a list of users
  • [ ] which when an account is clicked, will present a page using the same UI as the "profile" page for users
• [x] when clicking on "groups", be prompted with a list of groups
  • [ ] which when a group is clicked, will present a page showing details of the group
• [ ] when clicking on feral crab management, be scolded for judging crabs this way, there's no such thing as a feral crab
• [x] when clicking on oauth2 applications, be presented a list of RPs
  • [ ] which when clicked will show details of the RP (the secret should maybe be hidden by default?)

Describe alternatives you've considered

Using the CLI but I like clicking things.

Additional context

Yeah, we were talking about changing the API with respect to people vs service accounts but I wanna click the things.

[Firstyear]

So this is not super easy because:

• We need the server to indicate if a user can or can not "see" the admin ui link (which is kinda permission dependent but kinda not)
• The ability to show what you can and cannot edit (partially started via the permission test code as part of credential update)

It's been something in the back of my mind for a while, but we do need to really consider how to determine who would be shown what.

[yaleman]

Yep, for sure - similar to the OAuth2 RP list thing, it's going to force some investment into these kinds of REST endpoint things. I was going to go with a "assume the user has access, and handle permissions errors when making the calls" approach.

Editing's a whole other problem/issue/bag of nightmares 🤣

[Firstyear]

Well, it's still going to have access enforced on the server, but good UX would dictate we still "constrain" the UI to only show whats possible.

[TheRealGramdalf]

Just thought I'd add my two cents here:

• Spacedrive, another rust-based project, is using a PPRTT stack - I've heard good things about tauri, and it may be worth checking out
• Depending on various factors, I thought it might be worth going a route semi-similar again to portainer - but slightly different.
  • Keep Kanidm Server as it is right now - a standalone, primarily CLI server with a WebUI for SSO login and password reset
  • Use a separate client tool (WebUI, local desktop/mobile application, etc.) that interacts with the server directly with the API This would make managing security much simpler because of the client/server nature of things - as long as the API is secure, the client tool will be inherently secure (given you manage cookies and whatnot properly, of course). This would also keep Kanidm Server lightweight, since you don't need to be running the WebUI 24/7. There would be downsides, of course - such as making sure the client/server are always compatible, but there are always workarounds (such as the client/server declaring an API version to eachother).

Just thought I'd mention it, give some food for thought.

[yaleman]

That’s what the webui is currently - a single page app which runs client-side and interacts with the APIs.

On 2023-10-25 03:42 TheRealGramdalf wrote:

Just thought I'd add my two cents here:

• Spacedrive, another rust-based project, is using a PPRTT stack https://github.com/spacedriveapp/spacedrive#architecture - I've heard good things about tauri, and it may be worth checking out • Depending on various factors, I thought it might be worth going a route semi-similar again to portainer - but slightly different. • Keep Kanidm Server as it is right now - a standalone, primarily CLI server with a WebUI for SSO login and password reset • Use a separate client tool (WebUI, local desktop/mobile application, etc.) that interacts with the server directly with the API This would make managing security much simpler because of the client/server nature of things - as long as the API is secure, the client tool will be inherently secure (given you manage cookies and whatnot properly, of course). This would also keep Kanidm Server lightweight, since you don't need to be running the WebUI 24/7. There would be downsides, of course - such as making sure the client/server are always compatible, but there are always workarounds (such as the client/server declaring an API version to eachother). Just thought I'd mention it, give some food for thought.

— Reply to this email directly, view it on GitHub https://github.com/kanidm/kanidm/issues/996#issuecomment-1777723243, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABJB7APWFA6WJWHCWQBFOLYA742DAVCNFSM57EDGOO2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZXG43TEMZSGQZQ. You are receiving this because you were assigned.Message ID: @.***>