Admin → Security (/admin/security) is the React admin screen for the two things that decide what an account may do: wiki groups and policy grants. It replaced the legacy JSP admin pages. It is part of the SPA (wikantik-frontend/src/components/admin/AdminSecurityPage.jsx), and every action calls a REST servlet under /admin/* that AdminAuthFilter protects.
The page has two sections, switched by the buttons at the top.
Groups (/admin/groups and /admin/groups/{name}, AdminGroupResource)
Policy Grants (/admin/policy and /admin/policy/{id}, AdminPolicyResource)
policy_grants rows showing the principal (type badge and name), permission type, target and actions, with Edit and Delete on each row and + Create Grant above it.role, user or group), a principal name (for a user grant, the account's login name), a permission type (page, wiki or group), a target and the actions as checkboxes. The Grant AllPermission (full admin access) checkbox writes the canonical all / * / * row.* action on a page, wiki or group grant, and refuses AllPermission for the built-in roles All, Anonymous, Asserted and Authenticated. See Database-Backed Permissions for the table, the seeded defaults and the full rules.admin, action access, target set to the first path segment after /admin/, for example insights) appear in the grid but are created by POST /admin/policy, not by the form. They let an account reach one /admin/* area without AllPermission.AdminAuthFilter lets a request through when the session holds AllPermission, or a scoped admin grant for the area it targets. AllPermission comes from membership of the Admin group. An account that has only a row in the roles table authenticates but gets HTTP 403 on /admin/*. The SPA also redirects a signed-in user without the Admin role to /wiki/Main, but that is a convenience; the server-side filter is the control.
These sit beside Security in the admin sidebar and cover the rest of the access picture:
| Screen | Route | What it manages |
|---|---|---|
| Users | /admin/users | create, edit, delete, lock and unlock accounts, and bulk actions (AdminUserResource) |
| API Keys | /admin/apikeys | issue, scope (mcp_read, mcp_admin, tools, all) and revoke the bearer keys used by MCP and /tools/* clients; the plaintext token is shown once |
| Audit | /admin/audit | search the tamper-evident, hash-chained audit log, verify its chain, export CSV |
Group-membership changes are audited as group.member.add and group.member.remove, and grant changes as policy.grant.update and policy.grant.delete. Issuing a key is audited as apikey.issue and revoking one as apikey.revoke, whether done on /admin/apikeys (single or bulk, one entry per key) or through the self-service Preferences page; rotating a key (self-service only) is audited as apikey.rotate.
There is no session monitor or "kill switch", no token-lifecycle screen for OAuth2/OIDC tokens (single sign-on through pac4j only establishes a normal login session; Wikantik does not store the identity provider's tokens), no JWT claims cache, no Redis broadcast and no dual-control approval step. Revoking an API key is a soft delete on /admin/apikeys, and the in-process verification cache (60-second TTL) is evicted on the node that handled the revoke.
For the operator reference, see docs/admin/Security.md, docs/admin/AdminPanel.md, docs/admin/ApiKeys.md and docs/admin/AuditLog.md in the repository.
Cluster Hub: Wikantik Platform Development Hub: Architecture, MCP Protocols, and Agent Briefings (wikantik-development)