Pub access has three separate checks: a person signs in, the edge admits that identity to the Pub, and the Pub decides what that person may do. Passing one check never bypasses the next.
The access model
flowchart LR PERSON["Staff member"] --> SIGNIN["Shared staff sign-in"] SIGNIN --> ADMISSION["Pub admission"] ADMISSION --> ASSIGNMENT["Exact Pub permission assignment"] ASSIGNMENT --> ACTION["Allowed operator action"]
As the shared Authentik service is commissioned, it will provide staff identity and multifactor sign-in. Cloudflare Access remains the admission boundary in front of the product. Pub continues to own its roles and permissions.
This separation matters:
- an Authentik account does not automatically grant Pub access;
- admission to House Desk does not grant Pub access;
- admission to the Pub does not grant every operator action; and
- removing a Pub permission assignment takes effect independently of the person’s sign-in account.
For an operator
If you need access, ask a Pub administrator for the smallest permission assignment that covers your work. After it is assigned:
- open the protected Pub operator area;
- complete the normal staff sign-in;
- confirm that only the expected sections and actions are available; and
- report missing or unexpected access before changing live information.
The interface hides actions outside your role to reduce confusion. The service also checks every protected request, so hiding a button is never the security boundary.
For an administrator
Pub stores one exact permission assignment for each person. The admin interface offers reviewed bundles for common job shapes, but a bundle is a starting point rather than a reusable role with linked members. Changing a bundle definition does not silently update existing people.
When onboarding or changing access, start from the closest reviewed bundle, adjust the exact permissions for that person, and review the resulting assignment before saving.
Good access administration has four properties:
- Least privilege: grant only what the person’s current work requires.
- Clear ownership: each permission belongs to the Pub product, not to a shared identity provider.
- Traceability: changes are recorded so administrators can answer who changed access and when.
- Prompt removal: revoke product access when a role or staffing relationship ends.
Avoid sharing accounts. Each operator should use their own verified identity so activity remains attributable.
Troubleshooting
| What you see | Likely boundary | Next step |
|---|---|---|
| You cannot reach the sign-in page | Network or product admission | Ask a Pub administrator to confirm admission for your identity |
| Sign-in succeeds but the operator area is denied | Pub permission assignment | Ask an administrator to review your assignment |
| The page opens but an action is unavailable | Permission within the assignment | Confirm that the action is part of your assigned work |
| Access remains after a job change | Offboarding is incomplete | Contact an administrator immediately |
Do not send credentials, session links, or screenshots containing personal information through public support channels.
Technical boundary
The verified identity reaches the Pub as a signed claim. The service normalizes that identity, resolves the person’s exact Pub assignment, and checks the required capability on every protected request. Reviewed bundles are an administrative convenience; server-side permission enforcement is authoritative.
Related: Architecture · Scheduling