Raising the Bar for PAM: User Access Approvals
Raising the Bar for PAM: User Access Approvals
OpenOTP / WebADM now lets you require approvals before users get into sensitive systems. You can define approvers per application policy, choose how many approvals are needed, set approval time windows, make approvals one‑time or bound to a user’s IP, and exempt (allowlist) specific users. Approvals can be auto‑enforced or condition‑based (e.g., unusual country, not in a specific LDAP group). Everyone stays in the loop with email notifications. Combined with OpenOTP Network Access (NAC), you can even require approvals for new MAC addresses joining your network. Oh—and WebADM policies can now trigger email notifications on access and even collect user consent or signatures.
Why approvals for PAM?
Privileged Access Management (PAM) has long relied on MFA, time‑bound accounts, and role‑based controls. But high‑value targets—production SSH, admin consoles, VPN entry points—still need a human‑in‑the‑loop checkpoint when risk spikes. That’s what User Access Approvals bring to OpenOTP / WebADM: a simple, auditable, policy‑driven way to pause and verify before letting a session through.
Think of it as just‑in‑time, just‑enough access with an extra brain attached.
What’s new: approvals, per policy
Approvals are configured per application policy in WebADM. For each application (SSH, VPN, admin portal, etc.), you can specify:
- Number of approvers: Single approver, or multi‑party sign‑off (e.g., 2 of 3 admins).
- Approval time: A validity window (e.g., 30 minutes, 4 hours). After expiry, approval is no longer valid.
- One‑time approvals: Mark approvals as consumable once; each new access needs a fresh approval.
- Per‑user IP approvals: Bind the approval to the user’s source IP. If the IP changes, the approval no longer applies.
- User allowlisting (aka whitelisting): Exempt well‑understood accounts from approvals while keeping the policy for others.
Example scenarios
- Production SSH requires admin approvals.
- VPN requires approval outside official work hours.
- Application admin console requires a manager’s approval for escalated tasks.
Conditional enforcement: approvals when risk is unusual
Approvals don’t have to be “always on.” You can turn them on only when something looks off. For example, let the policy require:
- Membership in a specific LDAP group (e.g., prod-ops)
- Origin from allowed countries or corporate IP ranges
If a request does not meet those policy conditions—say the user is not in the right group or appears from an unexpected country—WebADM will trigger an approval rather than silently blocking or auto‑allowing. This keeps friction low for normal, compliant access while raising the bar for unusual patterns.
In short: approvals can be automatic oder conditional—your call.
End‑to‑end flow: what the user and approver see
- User requests access to a protected application (SSH, VPN, admin UI).
- Policy evaluation runs: time of day, group membership, geo/IP, device state (where applicable).
- If policy requires it, approval is requested.
- Approvers receive an email with the request details and action links.
- User receives an email acknowledging that approval is pending.
- Approver(s) approve or reject. If multi‑approver is configured, the required threshold must be met.
- User is notified of the result (approved or rejected). If approved, the user can proceed within the specified approval time window. If one‑time or IP‑bound, the approval is consumed accordingly.
Everything is logged for audit: who requested, who approved, when, from where, and why (if provided).
Policy options at a glance
- Approver list per application — Define approvers with flexibility (admins, managers, on‑call rotations).
- Quorum — 1 of N, 2 of N, etc.
- TTL (approval time) — Control how long the approval remains valid.
- One‑time vs. reusable — Choose whether approvals are consumed on first use.
- IP‑bound — Bind approval to source IP for session integrity.
- Allowlist — Bypass approvals for specific users or service accounts.
- Conditional triggers — LDAP group checks, country/region filters, business hours, and more.
- Email notifications — Automatic emails to both requesters and approvers for transparency.
Example policy ideas
1) Production SSH: “Two‑person rule”
- Trigger: Any SSH access to prod hosts.
- Approvers: SRE on‑call + platform lead; quorum: 2 of 2.
- TTL: 1 hour; one‑time: enabled; IP‑bound: enabled.
- Allowlist: None.
2) VPN: after‑hours control
- Trigger: Access outside 08:00–18:00 local time.
- Approvers: Security duty officer; quorum: 1 of 1.
- TTL: 4-8 hours; one‑time: enabled.
- Conditional: No approval during business hours if MFA + employees LDAP group.
3) Admin console: manager acknowledgment
- Trigger: Requests for the admin role in the application.
- Approvers: Team manager; quorum: 1 of 1.
- TTL: 2 hours.
- Allowlist: Head of platform.
OpenOTP NAC integration: approvals for new MAC addresses
When you connect OpenOTP Netzwerkzugriffskontrolle (NAC), you can extend approvals to the network edge:
- New MAC address appears on a protected segment.
- WebADM/OpenOTP raises an approval request to designated network admins.
- Upon approval, the MAC is authorized, and the device can proceed.
This reduces the back‑and‑forth with ticketing systems and makes it dead simple to keep your NAC infrastructure clean without compromising control.
Leistungen
- Faster onboarding for new devices with an auditable trail.
- Tighter control on what actually reaches your network.
- Unified approvals model across application and network access.
Email notifications, consent, and signatures
Two more policy‑level enhancements:
- Email notifications on access — WebADM policies can now fire email notifications whenever a user accesses a target application. This is great for sensitive apps where visibility matters even when approvals are not required.
- User consent & agreement signature — You can embed consent prompts and even require a user signature as part of the access policy. Think: acknowledging a production change window, agreeing to a data handling policy, or accepting a maintenance mode restriction.
Together, these features strengthen accountability und traceability, without forcing you to glue together external forms or brittle workflows.
Operational tips
- Define approver rotations: If you have an on‑call process, make that group an approver set so coverage is continuous.
- Use conditional approvals first: Start with low‑friction controls (after‑hours, outside country list, not in LDAP group) before turning approvals on for every access.
- Prefer one‑time + IP‑bound for high‑risk actions: It limits reuse and narrows the approval to the exact session.
- Allowlist sparingly: Keep the exception list short and reviewed. Service accounts and tightly audited leads only.
- Monitor notification volume: Too many emails = ignored emails. Tune conditions to keep signals meaningful.
What this means for your security posture
- Segregation of duties: Requiring another human to sign off reduces single‑actor risk.
- Adaptive friction: Normal, policy‑compliant access remains smooth; unusual access faces higher scrutiny.
- Auditability: Approvals, rejections, windows, IP bindings, and notifications create a detailed trail.
- Consistency: Application access and network access (via NAC) now share the same approval story.
Example user journey: VPN outside work hours
- Alice attempts VPN login at 21:30.
- WebADM sees it is outside business hours → approval required.
- Security duty officer receives an email with request details and the Approve/Reject action.
- Officer approves; WebADM records the event.
- Alice receives an approval granted email and can connect within the 30‑minute TTL.
- If Alice disconnects and reconnects after TTL, she will need another approval (since it is one‑time).
Häufig gestellte Fragen
Q: Does approval replace MFA?
A: No. Approvals complement MFA. Keep MFA enabled; use approvals as an extra, human‑verified step for privileged or unusual access.
Q: Can I route approvals to different approvers based on the app?
A: Yes, approver lists are per application policy. VPN can go to security, SSH to SRE, and app admin to managers.
Q: What if approvers miss the window?
A: Das TTL closes automatically. The request expires and the user can re‑initiate if still needed.
Q: Can approvals be tied to the user’s IP?
A: Yes, enable per‑user IP approval to bind the authorization to the originating IP.
Q: Can I bypass approvals for some users?
A: Yes, use user allowlisting for specific accounts that do not require approval.
Getting started
- Update to the latest OpenOTP / WebADM build that includes User Access Approvals.
- Identify target applications and group them by risk & sensitivity.
- Draft policies with:
- Approvers and quorum,
- Approval TTL, one‑time and/or IP‑bound,
- Conditional triggers (LDAP groups, countries, business hours),
- Notification preferences,
- Allowlist (if absolutely necessary).
- Start with a low‑risk pilot (e.g., VPN after hours), measure impact, then expand to production SSH and admin consoles.
Approvals make privileged access measurably safer without drowning teams in tickets. If you are already on OpenOTP / WebADM, turning this on is a short hop with a big payoff. And with NAC integration, you extend the same, sane controls to the network edge.
Next up: roll out conditional approvals, turn on access notifications for sensitive apps, and add consent/signature where policy acknowledgment matters.
