Task
The SSH Certificate Signer at extensions/SSH-Certificate-Signer/ issues short-lived, identity-bound OpenSSH user certificates so researchers can access HPC resources without managing long-lived SSH keys. Its HTTP API is in place but there is no user-facing way to view or manage certificates today.
This task builds a web dashboard for the signer. The first user-facing surface in the Custos portal, which will later host allocation management, project membership, and profile screens.
Design
The screenshot below shows the SSH Certificates list view in the broader portal layout. The flow continues with a certificate detail screen (reached via each row's "More" button) and a revoke confirmation dialog for active certificates.
The page has two access modes. A user sees only the certificates issued on their behalf. An admin sees all certificates across all users, including the Username filter shown in the screenshot. The "user" and "admin" distinction is a simplification of the broader Custos role model (PI, Co-PI, Allocation Manager, User). For this dashboard, anyone who is not an admin is treated as a user. Full role-based authorization is a follow-up task, this phase targets the user view.
Implementation
A new top-level portal/ directory at the repository root, scaffolded as a React + TypeScript single-page application. The signer pages are the first feature; future features (allocations, profile, project management) live alongside under the same portal.
portal/
├── src/app/
│ ├── signer/ ← this task
│ ├── allocation/ (future)
│ └── profile/ (future)
Prescribed stack (alternatives may be proposed with justification) - React 19, TypeScript, Vite, React Router v7, Tailwind CSS v4 with shadcn/ui, Vitest and Playwright for testing. All recommended dependencies are MIT or Apache-2.0 licensed.
The signer exposes user-authenticated endpoints behind OIDC Bearer tokens. The dashboard integrates:
| Method |
Path |
Purpose |
GET |
/api/v1/userinfo |
Resolve the signed-in user |
GET |
/api/v1/certificates |
List the user's certificates |
GET |
/api/v1/certificates/{serial} |
Certificate detail |
POST |
/api/v1/revoke |
Revoke a certificate |
Request and response shapes are in the signer's handler source at internal/handler/. POST /api/v1/revoke is still in progress on the backend; the contract and audit-log behavior are stable and the dashboard can integrate against the existing shape. Reflecting the revoked state on subsequent list and detail responses is being finalized in parallel.
The task delivers the portal scaffolding, an authenticated layout (sign in via OIDC, current user from /api/v1/userinfo, sign out), the three signer screens, unit tests for data-loading hooks, and at least one Playwright end-to-end test covering the list → detail → revoke happy path. For local development the signer supports a dev OIDC mode (see its config and README) so contributors can run the full flow without a real OIDC provider.
References
Task
The SSH Certificate Signer at
extensions/SSH-Certificate-Signer/issues short-lived, identity-bound OpenSSH user certificates so researchers can access HPC resources without managing long-lived SSH keys. Its HTTP API is in place but there is no user-facing way to view or manage certificates today.This task builds a web dashboard for the signer. The first user-facing surface in the Custos portal, which will later host allocation management, project membership, and profile screens.
Design
The screenshot below shows the SSH Certificates list view in the broader portal layout. The flow continues with a certificate detail screen (reached via each row's "More" button) and a revoke confirmation dialog for active certificates.
The page has two access modes. A user sees only the certificates issued on their behalf. An admin sees all certificates across all users, including the Username filter shown in the screenshot. The "user" and "admin" distinction is a simplification of the broader Custos role model (PI, Co-PI, Allocation Manager, User). For this dashboard, anyone who is not an admin is treated as a user. Full role-based authorization is a follow-up task, this phase targets the user view.
Implementation
A new top-level
portal/directory at the repository root, scaffolded as a React + TypeScript single-page application. The signer pages are the first feature; future features (allocations, profile, project management) live alongside under the same portal.Prescribed stack (alternatives may be proposed with justification) - React 19, TypeScript, Vite, React Router v7, Tailwind CSS v4 with shadcn/ui, Vitest and Playwright for testing. All recommended dependencies are MIT or Apache-2.0 licensed.
The signer exposes user-authenticated endpoints behind OIDC Bearer tokens. The dashboard integrates:
GET/api/v1/userinfoGET/api/v1/certificatesGET/api/v1/certificates/{serial}POST/api/v1/revokeRequest and response shapes are in the signer's handler source at
internal/handler/.POST /api/v1/revokeis still in progress on the backend; the contract and audit-log behavior are stable and the dashboard can integrate against the existing shape. Reflecting the revoked state on subsequent list and detail responses is being finalized in parallel.The task delivers the portal scaffolding, an authenticated layout (sign in via OIDC, current user from
/api/v1/userinfo, sign out), the three signer screens, unit tests for data-loading hooks, and at least one Playwright end-to-end test covering the list → detail → revoke happy path. For local development the signer supports a dev OIDC mode (see its config and README) so contributors can run the full flow without a real OIDC provider.References