Assisted Login Concepts

Assisted Login is Mideye Server’s human-in-the-loop access approval system. A designated approver — such as a helpdesk operator, team lead, or on-call engineer — must explicitly approve each authentication attempt before access is granted.

This eliminates standing access and ensures that even stolen credentials cannot be exploited without a real person’s conscious decision to authorize the session.

Note

For step-by-step setup instructions, see Configuring Assisted Login. For field-level reference of every UI element, see Assisted Login Profiles.

When to use Assisted Login

Assisted Login is ideal when you need a human to verify that an access request is legitimate before granting it — vendor access, break-glass scenarios, shared workstations, or any situation where “trust but verify” adds real security value.

How It Works

Assisted Login extends the standard RADIUS authentication flow with an approval step. Here is what happens during a typical login:

The Authentication Flow

1. User authenticates — The user connects through a RADIUS client (VPN, network switch, etc.) and provides their credentials. Mideye Server validates the first factor against the configured user repositories (local database, LDAP, or Entra ID).

2. Approver prompt — The server detects that the user requires assisted login and returns a challenge: “Enter Approver ID:”. The user types in their approver’s identifier — this can be a username, phone number, or email, depending on the profile configuration.

3. Approver lookup — The server searches for the approver across configured directories (local database, LDAP, Entra ID) and validates that the approver is authorized for this user based on the profile rules (group membership, identity list, manager relationship, or wildcard CN matching).

4. Challenge questions (optional) — If the profile has additional questions configured (e.g., “Enter your ticket number”), they are presented to the user one at a time. The answers are forwarded to the approver for review.

5. Approval request sent — The server contacts the approver:

   • Mideye+ push notification — if the approver has the Mideye+ app activated
   • Magic Link SMS — as a fallback if Mideye+ is not activated

6. Approver decides — The approver sees who is requesting access, from which system, and any challenge answers. They tap Accept or Reject. The result is returned to the RADIUS client.

The entire flow typically completes in under 30 seconds — the user waits while the approver receives and responds to the notification.

Profile Types

Mideye Server has two types of assisted login profiles, chosen at creation time. The type cannot be changed after creation.

Normal Profiles

The standard choice for most deployments:

• Single approver — The user identifies one specific approver during login
• LDAP/AD backed — Users and approvers are matched via directory groups
• Challenge questions — Optional additional questions for context gathering
• Configurable timeouts — Session and idle timeouts per profile
• Wildcard CN matching — Dynamic team-based pairing via group naming conventions

Federation Profiles

Designed for cross-organization or multi-approver scenarios:

• Multiple approvers — The system finds all valid approvers and notifies them simultaneously
• First responder wins — The first approver to respond determines the outcome
• Resource-based — Tied to a specific federated application or service
• Flexible user matching — Supports UPN, domain, and regex patterns
• Approver prioritization — An internal cache prioritizes approvers who have responded previously

Note

If you are unsure which type to use, start with a Normal Profile. It covers the vast majority of use cases. See Configuring Assisted Login for setup instructions.

Matching: Who Can Approve Whom?

Each profile defines two sets of rules: who may request assisted login (users) and who may approve those requests (approvers). A RADIUS client can have multiple profiles — the server evaluates them in order and uses the first profile where both user and approver pass validation.

Group-Based Matching

The most common approach. Add directory group names to the profile’s user and approver lists. During authentication, the server checks group membership.

Example: Users in VPN-Users can be approved by members of VPN-Approvers.

Identity-Based Matching

Explicitly list individual usernames for precise allow-listing. Useful for small teams or specific accounts.

Federation profiles support flexible identity formats: exact UPN (user@partner.com), domain (partner.com matches all users), or regex (.*@partner\.com).

Manager Matching (Normal Profiles Only)

Restricts approval to the user’s direct manager. The server compares the approver’s Distinguished Name against the user’s manager attribute in the directory. Best for organizations with clear reporting hierarchies.

Wildcard CN Matching (Normal Profiles Only)

For organizations with many teams following consistent naming conventions. Group names use patterns like .*TeamName-Users.* and .*TeamName-Approvers.*. The server extracts the shared keyword and matches users to approvers automatically.

User Group Pattern	Approver Group Pattern	Link
.*NorthRegion-Users.*	.*NorthRegion-Approvers.*	NorthRegion
.*SiteB-Operators.*	.*SiteB-Supervisors.*	SiteB

See Configuring Wildcard CN Matching for setup details.

Approval Methods

The server automatically selects the approval method based on the approver’s Mideye+ activation status.

Mideye+ Push Notification (Primary)

When the approver has the Mideye+ app activated, a push notification is sent containing:

• Who is requesting access (resolved from the profile’s Notification attribute, typically displayName)
• Which RADIUS client they are connecting through
• Any challenge question answers provided by the user

The approver taps Accept or Reject directly in the app.

For federation profiles, push notifications are sent to all valid approvers simultaneously — the first response determines the outcome.

Magic Link SMS (Fallback)

When the approver has not activated Mideye+, an SMS with a Magic Link is sent to their mobile number. The approver clicks the link in their browser to approve. A notice suggests activating the Mideye+ app for a better experience.

Caution

Magic Link fallback requires the approver to have a valid mobile phone number in the directory. If the number is missing or invalid, the approval request fails.

Audit Trail

Every assisted login event creates detailed audit records:

• Audit log — Records the username, approver, RADIUS client, source IP, and all challenge answers (event type: ASSISTED_LOGIN). Also available via Syslog integration.

• Authentication log — Captures the full authentication flow including challenge questions, answers, and session details.

• Error codes for failed attempts:

  Code	Meaning
  ASSISTED_LOGIN_FAILED	Rejection or timeout
  ASSISTED_LOGIN_APPROVER_MISSING_PHONE_NUMBER	Approver has no mobile number in directory
  ASSISTED_LOGIN_APPROVER_INVALID_PHONE_NUMBER	Approver’s phone number is malformed
  ASSISTED_LOGIN_FEDERATION_DELIVERY_FAILURE	Federation push failed — approver must open Mideye+

See Authentication Logs and Audit Logs for details.

Common Use Cases

Scenario	How Assisted Login Helps
Vendor & MSP access	External IT providers connect only when approved by internal staff. Eliminates standing VPN tunnels.
Help desk support	Support staff request temporary access per ticket. Manager or ticket owner approves. Full audit trail.
Shared workstations	Factory floors, labs, or kiosks. Supervisors approve access for team members instead of shared passwords.
Break-glass access	Emergency scenarios. Pre-authorized approvers grant immediate access while maintaining controls.
Healthcare & shift work	Clinical staff access patient systems with charge nurse or physician approval per shift.
Critical infrastructure	OT/ICS environments requiring dual authorization for remote maintenance access.

Next Steps

• Configuring Assisted Login — Step-by-step setup guide
• Assisted Login Profiles — Field-level reference for the admin UI