# 6. IP-Based Access Control

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*

---

## 6. IP-Based Access Control

### 6.1 IP Allow/Deny Lists
**What it does:** Restricts or permits platform access based on the IP address or range a request comes from. Deny lists block known-bad traffic (abusers, attackers, abusive ranges); allow lists restrict access to trusted networks (e.g., privileged roles only from office IPs). Lists can be scoped globally or per role, take effect immediately, and their hits are logged so the Super Admin can verify they are working and tune them.

**Sub-features:**
- Create allow lists (only listed IPs may access) and deny lists (listed IPs are blocked)
- Support for single IPs and CIDR ranges
- Scope per list: global, or restricted to specific roles (e.g., an allow list that applies only to admin roles)
- Entry management: add, edit, remove entries, each with a description and optional expiry
- Precedence rule: deny lists take precedence over allow lists when both match
- Immediate effect on new login attempts; optional enforcement on existing sessions
- Hit logging: which list entries are being triggered, how often, by which IPs/users
- List health view: entries with zero hits (candidates for removal) and heavily-hit entries
- Audit logging of all list changes

**Super Administrator User Journey:**
1. Security monitoring shows a burst of failed logins and scraping traffic from a range of IPs. Super Admin opens System Settings → Security Policy → IP Access Control.
2. Creates a deny list entry for the abusive CIDR range, with the description "Abusive range — failed login burst, incident [ref]" and no expiry (to be reviewed monthly).
3. Separately, to harden privileged access, Super Admin creates an allow list scoped to the Billing Administrator and Super Admin roles containing the office IP range, with the description "Office network — privileged roles".
4. Saves; both rules take effect immediately for new login attempts.
5. Super Admin reviews the hit log over the next day: the abusive range is being blocked (hit count rising, all denied), and office logins for privileged roles are passing the allow list.
6. A remote-working Billing Administrator is locked out from home (not on the allow list). Super Admin is contacted, confirms the user's identity and location, and temporarily adds the user's current IP range to the allow list with a 7-day expiry and the description "Remote work — [user], expires [date]".
7. At month end, Super Admin reviews list health: the abusive range still has hits (kept), an old entry has zero hits (removed), and the remote-work entry is near expiry (renewed or let lapse).
8. Super Admin exports the IP-list change audit log for the security audit evidence package.

**Rules & Edge Cases:**
- Deny lists take precedence over allow lists when both match an IP — a deny always wins.
- A role-scoped allow list that excludes a user's current IP blocks that user's next login until they are on a listed IP or the rule is adjusted; this is a common cause of "why am I locked out?" and is surfaced in the block message.
- Every block event is logged with the IP, the user (if known), and the specific list entry that triggered it.
- Entries support optional expiry so temporary allowances (remote work, incident response) do not become permanent.
- Changes to lists (add/edit/remove) are audit-logged with the acting admin and the entry details.
- Enforcement on existing sessions is optional: by default, lists gate new logins; an admin can choose to also cut off existing sessions from a newly-denied IP.

### 6.2 Location-Based Access Restrictions
**What it does:** Restricts access based on the approximate geographic location derived from the user's IP, complementing exact IP lists with location-level rules. Used to confine privileged roles to the operating country/region and to detect impossible-travel patterns through velocity checks, which raise review alerts rather than silently blocking.

**Sub-features:**
- Block or allow access by country/region
- Per-role location policies (e.g., admin roles restricted to the operating country)
- Velocity checks: flag logins from vastly different locations within a short window (e.g., two continents in an hour)
- User notification when a login is blocked by location policy, with the reason and support contact
- Admin review queue of location-blocked and velocity-flagged login attempts
- Configurable: velocity alerts as review items or (optionally) automatic blocks
- Logging of all location-based blocks and velocity flags

**Super Administrator User Journey:**
1. Super Admin opens System Settings → Security Policy → Location Restrictions.
2. Configures the allowed region for privileged roles: Super Admin, Billing Administrator, and staff roles may log in only from the operating country.
3. Enables velocity checks with a threshold: two successful logins from different continents within 60 minutes raises a critical alert.
4. Saves the policy; it applies to new login attempts from that point.
5. A staff member traveling for a conference attempts to log in from abroad and is blocked by the location policy. They see "Access from your current location is not permitted for your role. Contact support if this is unexpected." and contact support.
6. Super Admin verifies the travel is legitimate and grants a temporary location exception for that user (with an expiry matching the trip), which is audit-logged.
7. On another day, a velocity alert fires: an account logged in successfully from two continents 40 minutes apart. Super Admin opens the alert in security monitoring, reviews both login events (devices, IPs, methods), and determines the second is unauthorized.
8. Super Admin takes the standard compromise response: force logout all sessions, trigger a password reset, suspend the account pending user contact, and resolves the alert with outcome notes.
9. Super Admin reviews the location-block and velocity-flag queue weekly to confirm each item was actioned and to tune thresholds where false positives are recurring.

**Rules & Edge Cases:**
- Location is approximate (IP-derived); rules are applied at country/region level, not city level, to avoid false blocks from IP-geolocation imprecision.
- VPN and mobile-carrier NAT usage can shift apparent location; velocity alerts are review items by default, not automatic blocks (automatic block is a configurable, stricter setting).
- A location block is always communicated to the user with the reason and a support path, so legitimate travel does not dead-end silently.
- Temporary location exceptions are time-boxed and audit-logged; they expire automatically.
- All location-based blocks and velocity flags are logged and visible in the admin security dashboard.
- Location policy changes apply to new login attempts; they do not retroactively terminate existing sessions (except where an admin explicitly does so).

### 6.3 Geo-Restrictions
**What it does:** Controls the geographic availability of the platform or of specific content, based on the user's IP at access time. Used for licensing and content-rights compliance (e.g., video content licensed only for certain regions), service-availability scoping (countries where the platform operates), and regulatory requirements. Distinct from access control (section 6.1–6.2): geo-restriction governs what is available where, not who may log in.

**Sub-features:**
- Platform-level geo availability: the set of countries/regions where the service operates
- Content-level geo-restrictions: specific content items or categories unavailable in certain regions
- Enforcement at access time based on the user's current IP (server-side)
- Clear messaging when access is geo-blocked ("This content is not available in your region")
- Admin configuration of restriction lists per content item or category
- Geo-block hit statistics: demand in restricted regions, per content item
- Logging of all geo-block events for licensing compliance reporting
- Integration with content management: restrictions set on the content item and inherited by its delivery

**Super Administrator User Journey:**
1. A new video course is licensed only for the domestic market. Super Admin opens the content item in Content Management and selects its geo-restriction settings.
2. Adds the restricted regions (all regions except the licensed one) with the note "Licensing: domestic only — agreement [ref]".
3. Saves; the restriction applies immediately to playback of that content.
4. A user in a restricted region attempts to play the content and sees "This content is not available in your region." The rest of the platform remains usable to them.
5. Super Admin reviews the geo-block hit statistics for the item: a meaningful number of attempts from one restricted region indicates demand.
6. The content owner later expands the license to that region. Super Admin updates the restriction list to remove the region, and the content becomes available there immediately.
7. For the annual licensing compliance report, Super Admin exports the geo-block event log for the licensed content, showing that no playback occurred in unlicensed regions.
8. Super Admin reviews platform-level geo availability to confirm the operating-country list matches the current business scope, and updates it when the platform expands to a new country.

**Rules & Edge Cases:**
- Geo-restriction checks happen at content access time, so a traveling user may see availability change as their IP region changes.
- Restrictions are enforced server-side; they cannot be bypassed by client-side manipulation or URL guessing.
- A geo-block affects only the restricted content (or platform, for platform-level rules); it does not log the user out or block their account.
- All geo-block events are logged with content item, user (if authenticated), region, and timestamp, supporting licensing compliance reporting.
- Restriction changes (add/remove regions) are audit-logged with the acting admin and the licensing reference.
- Where a content item has both category-level and item-level restrictions, the stricter (union of) restrictions applies.