Admin & Staff Management / RBAC System

Use the live demo to test the complete staff onboarding, permissions and account lifecycle workflow from both the Master Administrator and Staff perspectives.

Demo Master Administrator
Username: admin
Password: admin123

1. Invite Staff
Log in as Master Administrator → open Invite Staff → enter an email address → send the invitation.

2. Register Staff
Open the invitation received by email → follow the secure registration link → complete the registration form → create a password → click Register → return to Staff Login.

3. Login as Staff
Sign in using the newly registered staff account. This lets you test the system from the staff user's perspective.

4. Test Direct Permissions
Return to Master Administrator → Manage Staff → select the staff member → add a permission.

Return to the Staff account and confirm that the permitted area becomes available. Remove the permission and verify that the Staff account loses that access.

5. Test Staff Lifecycle
From Manage Staff, test administrative lifecycle actions including Block, Unblock, Remove, Restore and Permanent Delete. Authentication behavior changes according to the staff member's current account state.

6. Test Role-Based Permissions
Create a reusable Security Role, assign predefined permissions to the role, then assign that role to the staff member through Manage Staff Permissions.

Return to the Staff account and verify that the permissions associated with the assigned role are available without manually granting each permission.

Permission Model:
Effective Permissions = Role Permissions + Direct Staff Permissions

Demo note: Please use test information only. Do not enter sensitive, confidential or real organizational data.

Designed a flexible authorization system that supports both reusable Security Roles and Direct Staff Permissions, allowing access to be managed efficiently at both role and individual-user levels.

Administrators can create Security Roles and assign predefined permission keys to them. Roles can then be assigned to staff members instead of manually configuring every permission for every user.

When individual exceptions are required, Direct Permissions can be granted to a specific staff member without creating an additional role.

The final authorization model is:

Effective Staff Permissions = Role Permissions + Direct Staff Permissions

The Staff application dynamically reflects the user's current effective permissions, allowing authorized modules to appear when access is granted and disappear when access is removed.

The frontend is not treated as the security authority. Backend authorization remains authoritative, ensuring that hiding or displaying an interface element does not determine whether a protected operation is actually permitted.

This architecture provides a reusable authorization foundation for connecting future administrative modules including Blogs, Careers, Contact, Ecommerce, Pages and Support.

Built a secure invitation-based onboarding workflow that allows the Master Administrator to control who can register as a staff member instead of exposing unrestricted public staff registration.

The onboarding lifecycle follows:

MasterAdmin Invitation → Email Delivery → Secure Invitation Link → Staff Registration → Active Staff Account → Staff Login

Each invitation uses a secure token with database hashing and expiration controls. Raw invitation tokens are not stored in the database, reducing exposure if stored invitation data is compromised.

The system supports invitation expiry, resend and revocation, while preventing stale or previously invalidated invitation links from being reused.

Production SMTP email delivery is integrated using Nodemailer with environment-controlled configuration for mail server credentials, sender information and security settings.

Once the invited user completes registration and creates a password, the invitation transitions into a registered staff account and the user can authenticate through the separate Staff Login environment.

The complete workflow was validated in production, including invitation creation, real email receipt, registration, successful staff authentication and rejection of stale invitation links.

Engineered separate authentication and session domains for Master Administrator and Staff identities, allowing both users to remain authenticated simultaneously in the same browser without their sessions overwriting or interfering with each other.

Each identity uses independent refresh and CSRF cookies:

Staff: staffRefreshToken + staffCsrfToken
MasterAdmin: masterAdminRefreshToken + masterAdminCsrfToken

Implemented asymmetric RS256 JWT authentication using separate access and refresh RSA keysets, 3072-bit RSA keys, Key IDs (kid), current/previous key support for rotation, and a public JWKS endpoint that exposes verification keys without exposing private signing keys.

Session security includes refresh-token rotation, replay protection, session revocation, HttpOnly refresh cookies, Secure cookies in production, SameSite protection, CSRF protection and controlled credentialed CORS.

Security-sensitive account actions are connected to session state so that lifecycle and password changes can invalidate relevant authentication sessions rather than allowing outdated sessions to remain active.

JWT private keys are protected at the infrastructure layer through read-only secret mounts, while production containers run with restricted privileges.

This architecture creates clear security boundaries between privileged administration and normal staff access while supporting secure browser-based authentication in production.

Built a complete staff account lifecycle that allows administrators to securely manage users from initial onboarding through account suspension, removal, restoration and permanent deletion.

The lifecycle supports:

Invited → Registered / Active → Blocked → Unblocked → Removed → Restored → Permanently Deleted

Lifecycle states are connected to actual authentication and session behavior rather than functioning only as administrative labels.

When a staff account is blocked or removed, the user can no longer authenticate. Security-sensitive lifecycle changes invalidate relevant session state to prevent previously authenticated sessions from continuing to provide access.

When an account is unblocked or restored, the staff member can authenticate again while retaining the appropriate account configuration.

Permanent deletion is treated as an explicitly destructive operation. The administrator must open a confirmation dialog and type:

DELETE

before the operation becomes available, reducing the risk of accidental permanent deletion.

The administrative interface is also state-aware, presenting only lifecycle actions appropriate to the staff member's current status rather than exposing invalid operations.

Password management follows the same security model. Staff password changes require current-password verification, securely replace the stored password hash, invalidate relevant previous authentication state, and ensure the old password can no longer be used.

The complete lifecycle was validated through production workflows covering block/unblock, remove/restore, permanent deletion, password changes and subsequent authentication behavior.

Deployed the Admin & Staff Management system using a containerized production architecture designed to separate public traffic, application services, database access and sensitive authentication infrastructure.

The production request path follows:

Internet → HTTPS Host Nginx → Application Containers → PostgreSQL

The system runs separate Node.js API and static Nginx client containers orchestrated through Docker Compose, with the host Nginx server providing reverse proxying and HTTPS/TLS termination.

Both application containers were hardened to reduce unnecessary privileges. The Node.js API runs as a dedicated non-root UID/GID 10001, while the client Nginx container runs under UID/GID 101.

Container security includes:

Non-root execution · cap_drop: ALL · no-new-privileges · read-only JWT secret mounts · loopback-only host bindings

The PostgreSQL database is not exposed publicly, restricting database access to the required application infrastructure.

Sensitive RSA JWT signing material is mounted into the backend container as read-only secrets, while the public JWKS endpoint exposes only the keys required for token verification and never exposes private signing keys.

Production operations include Docker builds, Docker Compose orchestration, Prisma migration deployment, permission seeding, MasterAdmin bootstrap, RSA key generation, SMTP verification, health checks and environment-based configuration.

The deployed system was validated through live HTTPS browser workflows, API health checks, JWKS verification, authentication/RBAC testing, SMTP delivery and production database operations while coexisting with the broader SignalGrowth applications.