Category filter

Attribute-Based Access Control (ABAC): Logic Gates for Conditional Login

1. Overview

Attribute-Based Access Control (ABAC) extends traditional authentication models by evaluating multiple contextual attributes before granting access. While Role-Based Access Control (RBAC) evaluates static identity attributes (such as job role), ABAC evaluates a dynamic combination of:

User attributes
Device compliance state
Network conditions
Environmental context

In a Zero-Trust architecture using Hexnode UEM, ABAC is implemented through coordinated enforcement between Hexnode UEM (Device compliance & endpoint posture evaluation) and an Identity Provider (IdP) such as Microsoft Entra ID or Okta.

Evaluation Flow

Hexnode evaluates device posture using configured compliance policies.
Device compliance state is synchronized to the IdP/partner ecosystem.
The IdP (Entra ID or Okta) evaluates authentication and Conditional Access policies.
Access decisions are enforced entirely by the IdP.

If any required condition evaluates to FALSE, access is blocked or additional controls (such as MFA) are enforced.

2. Defining the Logic Gates

An ABAC policy operates on structured conditional logic: If (User Attribute) AND (Device State) AND (Network Condition) > Then Grant Access. Because enforcement occurs across control planes, responsibilities are clearly divided:

Attribute Type	Evaluated By	Logic Gate Example	Requirement
User	IdP (Entra ID / Okta)	Department	Must be “Finance”
Device	Hexnode UEM	Compliance Status	Must be Compliant
Environment	IdP (Entra ID/ Okta) / Hexnode (Policy)	Named Location	Must be Trusted IP Range
Device Location	Hexnode (Policy)	Geofencing Rule	Must match defined policy
Final Decision	IdP	Conditional Access	All required conditions must be TRUE

3. Configuration Steps (Hexnode + IdP Integration)

Step A: Directory Integration (User Synchronization)

Hexnode supports direct directory synchronization for major Identity Providers.

Navigation Paths:

For Microsoft Entra ID: Admin > Microsoft Entra ID
For Okta: Admin > Okta

This integration enables user synchronization, user group synchronization, device identity mapping, and compliance partner reporting enablement. User attributes such as Department and Title are evaluated natively by your IdP. Hexnode does not use directory attributes for login enforcement.

Step B: Defining Device Compliance Gates

Hexnode continuously evaluates endpoint posture entirely through its Compliance Policies.

Navigation Path: Policies > Compliance Policies

Administrators define specific compliance rules to evaluate device health. Supported compliance checks include:

Device Inactivity: Marking devices non-compliant if they fail to communicate with the server for a specified number of days.
Device Encryption: Enforcing BitLocker for Windows or FileVault for macOS.
Passcode Compliance: Enforcing minimum passcode length, age, and complexity requirements.
OS Version: Enforcing minimum allowed OS builds.
System Integrity: Jailbreak (iOS) and Root (Android) detection.
Application Compliance: Mandatory application presence and blocklisted application detection.
Geofencing: Marking a device non-compliant if it exits a defined geographic boundary.

If a device violates any configured rule, Hexnode instantly updates the device status to Non-Compliant.

Step C: Compliance Status Flow to Conditional Access

Hexnode integrates with Microsoft using the Partner Compliance model.

Telemetry Flow: Hexnode UEM > Microsoft Intune (Partner Compliance Connector) > Microsoft Entra ID Conditional Access

Note:

While Okta handles identity and SSO, device compliance telemetry routing for Conditional Access specifically relies on Microsoft’s Partner Compliance API when evaluating device health for Microsoft 365 cloud apps.

Configuration in Microsoft:

Log in to the Microsoft Entra ID portal.
Navigate to: Tenant administration > Connectors and tokens > Partner compliance management.
Add Hexnode as a compliance partner for supported platforms.

Step D: Device Registration Requirement

For Conditional Access policies requiring compliant devices, devices must be registered (Azure AD Registered, Joined, or Hybrid Joined as applicable).

On certain platforms, a Microsoft broker application may be required (such as Microsoft Authenticator or Company Portal) to complete identity binding. Compliance evaluation occurs only after the device identity is properly associated with the user’s Entra ID account.

In Microsoft Entra ID: Navigate to Protection > Conditional Access > Create New Policy.

Configuration:

Assign Users or Groups.
Select Target Cloud Applications.
Configure Conditions (e.g., Named Locations, Platforms).
Under Grant Controls, select: Require device to be marked as compliant.

Result: If Hexnode reports the device as Non-Compliant, the IdP blocks access and displays a compliance requirement message to the user. All enforcement occurs at the IdP layer.

4. Advanced Scenario: Controlled Restriction Workflow (“Emergency Gate”)

Hexnode does not evaluate user risk signals from Identity Protection tools. Risk-based blocking is enforced at the IdP level. However, automated remediation can be implemented at the device layer.

IdP-Level Risk Enforcement

Identity Providers can block high-risk users, require MFA for risky sign-ins, and restrict session access dynamically.

Hexnode Device-Level Restriction

Hexnode supports Dynamic Device Groups based on compliance status, platform, ownership, and custom attributes.

Example Workflow:

Criteria: Compliance Status = Non-Compliant
Devices automatically enter a Dynamic Group, which can trigger the deployment of restrictive policies, removal of corporate access configurations, or security lockdown profiles.
Administrative Remote Actions(from Manage > Devices): Lock Device, Corporate Wipe (removes managed data where supported), or Wipe Device (factory reset).

5. Troubleshooting the ABAC Flow

Issue: Compliance Sync Timing

When a device becomes compliant, the following propagation sequence occurs:

Hexnode updates the compliance state.
Compliance status is relayed to Microsoft Intune.
Entra ID re-evaluates Conditional Access at the next authentication attempt.

Short propagation delays may occur due to synchronization intervals. Administrators can manually trigger a device sync from the Hexnode console to accelerate updates.

Issue: Access Blocked Due to Network Controls

If login is blocked, verify the IdP Named Locations configuration and confirm IP ranges are correctly defined. Remember: Hexnode geofencing affects device policy, not cloud login enforcement directly.

Issue: Missing User Attributes

If Conditional Access depends on attributes like Department, ensure the attribute is populated natively in the IdP (Entra ID/Okta). Hexnode does not manage or validate directory metadata for access control.

6. Audit & Monitoring

Device Compliance Monitoring

Navigation Path: Reports > Built-in Reports

Administrators can generate reports for Compliant devices, Non-compliant devices, Passcode compliance, and Encryption status.These reports support remediation planning and audit readiness.

Access Monitoring (IdP)

In Entra ID, review Sign-in Logs and Conditional Access Insights. These logs show which policy was applied, whether access was granted or blocked, and whether the “Require device to be marked as compliant” control caused the denial.