Local Authority Portal
Roles, permissions and audit
Access is least-privilege by design, derived from the Authority's own directory, enforced on the server, and evidenced by a tamper-evident audit trail.
Role definitions
- LA Officer
- Climate action staff in a single local authority
- LA Approver
- Nominated approver signing off that authority's submissions
- CARO Regional Editor
- Regional office staff curating content for their region
- CARO National Editor
- National team publishing across all four regions
- Administrator
- Platform administration; no editorial publishing rights by default
- Auditor
- Read-only assurance role for internal audit and the Authority's DPO
Permission matrix
“Own authority” means the action is permitted only for records scoped to the user’s own local authority, or for a regional editor, only within their region.
| Capability | LA Officer | LA Approver | CARO Regional Editor | CARO National Editor | Administrator | Auditor |
|---|---|---|---|---|---|---|
| View restricted resources | Read only | Read only | Full | Full | Read only | Read only |
| Create / edit submissions | Own authority | Own authority | Full | Full | No access | No access |
| Approve submissions | No access | Own authority | Full | Full | No access | No access |
| Publish to the public site | No access | No access | Own authority | Full | No access | No access |
| Manage authority profile & plan record | No access | Own authority | Own authority | Full | No access | No access |
| Invite / deactivate users | No access | No access | Own authority | Full | Full | No access |
| Manage roles and entitlements | No access | No access | No access | No access | Full | No access |
| Read the audit log | No access | No access | Own authority | Full | Full | Full |
| Export personal data / handle DSARs | No access | No access | No access | No access | Full | Read only |
Identity and session controls
Authentication
Organisational sign-in via the Authority's identity provider using OpenID Connect. No local passwords are created, stored or reset by the platform.
Multi-factor authentication
Required for every portal role with no self-service opt-out. Phishing-resistant methods are preferred where the Authority's tenant supports them.
Authorisation
Every permission is evaluated server-side on each request against the signed token's claims. Hiding a button in the interface is never treated as a control.
Authority scoping
An officer's authority is derived from directory group membership, not from a free-text field the user can type — closing the Stage 0 self-declaration weakness.
Session lifetime
Short-lived access tokens with silent renewal, absolute session expiry, idle timeout with a visible warning, and sign-out that revokes server-side state.
Cookies
Session cookies are HttpOnly, Secure, SameSite=Lax and host-prefixed. No analytics or session-replay technology is permitted on any authenticated page.
Joiners, movers, leavers
Access follows directory group membership, so a leaver loses access when the Authority disables the account — not when someone remembers to tell the supplier.
Privileged access
Administrator and Auditor roles are assigned to named individuals, reviewed quarterly, and every privileged action is written to the audit log.
Audit trail
Every authentication event, permission decision, content change and administrative action is recorded. Records are append-only, hash-chained so deletion is detectable, retained to the Authority’s schedule, and exportable for internal audit.
- Timestamp (UTC, monotonic)
- Actor identifier (directory subject, never a typed name)
- Actor role at the time of the action
- Authority scope
- Action and object identifier
- Before / after state for content changes
- Source network address and user agent
- Correlation identifier across services
- Outcome (allowed, denied, error)
Audit records are operational security data, not analytics. They are never used for behavioural profiling and are not shared with any third-party product.
ProvenanceStage 0 observed the live portal using local accounts with no multi-factor authentication and a free-text “Local Authority” field at registration. Both weaknesses are closed by the model above. Final role names, group mappings and retention periods are set with the Authority’s ICT and information governance teams at Stage 6.