60 lines
2.9 KiB
Markdown
60 lines
2.9 KiB
Markdown
# Web UI Audit Report
|
|
|
|
## Target Architecture
|
|
|
|
The target architecture for the Web Application (Identity Provider UI) relies on
|
|
the `auth-yes/ui` directory providing a full suite of authentication and
|
|
administrative management workflows. It must enforce a clean separation of
|
|
concerns using the Atomic Architecture model (Pure Logic, I/O Reads, Explicit
|
|
Side Effects) utilizing Deno Hono and `hono/jsx`. The architecture requires a
|
|
fully functional client-side WebAuthn workflow handling registration and
|
|
cross-device authentication gracefully.
|
|
|
|
Key capabilities required:
|
|
|
|
- **Core Authentication:** Secure, hardware-bound WebAuthn registration and
|
|
login.
|
|
- **Administrative Dashboard:** Dedicated UI to manage user provisioning
|
|
(generate invite codes), toggle user statuses, and review system audit logs.
|
|
- **Passkey Management Panel:** User-facing dashboard to register multiple
|
|
redundant passkeys (platform and roaming) and selectively revoke compromised
|
|
authenticators.
|
|
- **Multi-tenant / Multi-persona UI:** A clean interface mapping localized user
|
|
metadata while retaining secure central UUID references.
|
|
|
|
## Completed
|
|
|
|
Based on an audit of the `auth-yes/ui` directory, the following foundation is
|
|
established:
|
|
|
|
- **UI Framework Initialization:** The foundational Hono JSX UI application is
|
|
mounted at `auth-yes/ui/mod.ts`.
|
|
- **Atomic Architecture Adherence:** Explicit separation of route rendering and
|
|
static asset serving in `mod.ts`, keeping view components isolated.
|
|
- **Basic Auth Routes:** Endpoints for `/login` (`LoginPage.tsx`) and
|
|
`/register` (`RegisterPage.tsx`) are currently implemented.
|
|
- **Client-Side WebAuthn Mechanics:** The `public/auth-client.js` script
|
|
successfully maps `navigator.credentials.create()` and
|
|
`navigator.credentials.get()` to the underlying API Gateway challenges.
|
|
|
|
## Missing/To-Do
|
|
|
|
A significant portion of the administrative and user-management workflows
|
|
outlined in the IAM architecture document remains to be built:
|
|
|
|
- **Administrative Dashboard UI:** The system currently lacks the frontend
|
|
routes and components necessary for administrators to generate invite codes,
|
|
toggle user states (e.g., from "pending" to "active"), and review the central
|
|
PostgreSQL audit logs.
|
|
- **Redundant Passkey Management Panel:** There is no user-facing UI allowing
|
|
users to register secondary/backup authenticators or manually revoke
|
|
compromised devices.
|
|
- **WebAuthn UX Polish:** The current login/registration components lack
|
|
polished UX flows for cross-device authentication (e.g., guiding users to plug
|
|
in hardware tokens or scan QR codes explicitly).
|
|
- **Session Review Interface:** The UI needs a view for users to query their
|
|
active session tokens and historical connection logs to actively monitor for
|
|
compromised sessions.
|
|
- **Component Modularity:** Need to establish shared layout headers/footers to
|
|
support the expansion of the dashboard and settings views.
|