QC User Impersonation Security Model Overview

QC User Impersonation Security Model Overview explains the current QCUI 1.0.03 behavior and how it affects a Super User who needs to inspect the Joomla frontend as an eligible user.

Defense in depth

  • Super-User-only initiation: QCUI requires Joomla core.admin on the issuing identity.
  • Shared Sessions refusal: QCUI stops rather than risk replacing the administrator identity when Joomla is configured to share site/admin sessions.
  • Short-lived one-time token: configurable 30–300 seconds, 60 seconds by default, with atomic single-use consumption.
  • Hashed-at-rest secret: only the SHA-256 token hash is stored in the database.
  • Double validation: administrator authority and target eligibility are checked again at consumption time.
  • CSRF and cache controls: start/end actions use Joomla tokens; handoff responses are no-store/no-cache with a no-referrer policy.
  • Session isolation: the frontend session is forked instead of replacing the existing administrator session.

Data minimization

The raw handoff secret is not stored; QCUI stores its SHA-256 hash. No target password is requested. Audit data records IDs, timestamp, IP/user-agent and short event details rather than authentication credentials.

Final control

A visible banner makes the support identity explicit, and End impersonation changes only that frontend session to guest. These layers work together; none should be removed because another layer exists.

Community Discussion

Want to compare support workflows, share practical tips, or discuss how you use this QCUI feature? Visit the QC User Impersonation Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.