SUIT - Security & Unified Identity Toolkit

Just-in-time privilege, separation of duties, access reviews and step-up re-authentication for Drupal 11, with a verifiable audit trail. Developed and maintained by StellerSight Private Limited. Current release: 1.0.0-rc1, a release candidate; 1.0.0 follows a two-week soak.

Administrative access in Drupal is usually permanent: a role is granted and stays until someone removes it. For the roles you manage through SUIT, access becomes time-bounded instead. Users are made eligible for a privileged role, request it with a justification when they need it, and hold it only for an approved window. The role is never written to their account.

Privileged identity management (suit_pim)

• Eligibility, not assignment. A user eligible for a role holds nothing until a request is approved. Requesters cannot approve their own requests unless self-approval is explicitly enabled; eligibility can also be marked as not needing approval.
• Granted at calculation time, never stored. Built on Drupal 11's access policy API: an active grant adds the role's permissions when permissions are calculated. The user__roles table is never changed.
• Ends on time without cron. Calculated permissions are cached for less than the remaining window, so access ends at the moment of expiry even if cron does not run. Tested with no cache invalidation and no cron.
• Bounded. No grant exceeds 4 hours; per-role ceilings and individual eligibility can only be shorter.
• Bound to the role as approved. If the role's permissions or administrator flag change, the grant stops and is revoked permanently.

Access reviews (suit_review)

• Campaigns freeze the active eligibilities; a reviewer, never the subject, retains or revokes each one, with a justification. A revoked or suspended eligibility is never silently restored.
• Eligibility not retained by the deadline stops working at the deadline, without waiting for cron. Certification expires after a configurable age (default 90 days) and is bound to the eligibility, the role's permissions and the separation-of-duties policies at the time: if any of them changes, the eligibility is refused until reviewed again.

Separation of duties and dormant accounts (suit_iam)

• Policies name roles that must not be held together, enforced strictly or recorded as warnings, including roles held through active grants.
• Optional detection of dormant accounts (off by default), which reports them with an audit event. It does not block accounts: there is not yet a tested recovery path or exclusions for service and emergency accounts.

Step-up re-authentication

• Approving, rejecting or revoking an elevation, creating, changing or deleting eligibility, deciding an access review, and creating, changing or deleting a separation-of-duties policy require the acting user to have confirmed their password recently. Enforced on the routes and in the services that make these decisions, for everyone who can make them; users without the permission get an ordinary access-denied page. One confirmation opens a window (10 minutes by default) that covers every such decision until it ends.
• Optional privileged-session controls (suit_pam): idle timeout, IP binding, and step-up on additional routes and on changes to roles, accounts and actions.

Audit trail

• Security events from every SUIT submodule are written to the audit log. Events are hash-chained in a documented format (suit.audit.v1) that SUIT for Linux shares; drush suit:verify reports edited or removed events.
• The chain is tamper-evident, not immutable: it is unkeyed, so someone with database write access could rebuild it. Forward events to syslog or a SIEM where independent evidence matters.
• Retention is off by default, and so is recording client IP addresses and User-Agents (IP addresses are personal data).

What SUIT does not do

• It is not an authentication module. Step-up is password re-entry, not multi-factor authentication; use TFA or WebAuthn for sign-in. Accounts without a local password (single sign-on) cannot complete step-up yet, and there is no API flow to complete it: an API client's user must confirm in a browser session.
• Roles assigned directly on the user form remain standing privilege; SUIT governs the roles you manage through it.
• There is no emergency (break-glass) access and no notifications yet.
• Code that saves eligibility or policy entities directly is trusted and not intercepted; enforcement covers forms, REST, JSON:API and SUIT's own decision services.

Evidence

• Kernel, unit and browser tests; PHPCS, PHPStan and CSpell, all blocking in Drupal.org CI.
• Upgrades from 1.0.0-beta2 through beta6 tested; concurrency measured on MySQL 8.0 and PostgreSQL 16.
• A conformance matrix maps each security invariant to its enforcement and tests: docs/assurance/CAG-CONFORMANCE-MATRIX.md.
• OpenSSF Best Practices: passing.

Requirements

Drupal 11. No third-party PHP libraries and no external services.

Related

• DPDP Compliance Toolkit: statutory records for consent, purpose binding, Data Principal rights and guardian authorizations under India's Digital Personal Data Protection Act, 2023.
• Cyber Incident Register: incident reporting clocks under CERT-In, DPDP Rule 7 and GDPR Article 33.

AI tools assisted with code, tests, reviews and documentation. The maintainer directs the work and approves every release.