Access Policies

An Access Policy is the ruleset a Sign-In Context consults every time a guest arrives at the Captive Portal (or signs into the Self-Service Portal). A policy answers three questions:

1. Who does this policy apply to? — matched by email pattern or email domain.
2. Which Sign-In modules is this guest allowed to use? — Meeting Host, Email Self-Provisioning, SAML.
3. Which Self-Service actions can this guest perform? — Manage Conferences, Manage Whitelistings.

Every Context has a default policy that catches anyone no other policy matches. You can add additional policies and give each a list of email patterns to define its audience.

Where policies live

In the Sign-In Context admin, open the Captive Portal → Access Policies section in the left navigation. The list view shows, for each policy:

• Name
• Who (Applies To) — the email patterns
• Sign In Permissions — teal pills per enabled Sign-In module
• Self-Service Permissions — green pills per enabled Self-Service action, or a red Self Service Not Enabled pill when the Self- Service Portal is off for the policy

Click a row to open the policy editor.

The editor — three tabs

Each policy editor has a shared header with three cards — Policy Name, Self-Service Portal (the master-switch for this policy’s Self-Service actions), and Site Based Redirect (when on, defer this policy’s redirect to the per-Site URL in Sites Configuration).

Below the header, the editor has three tabs:

1. Applies To

The single set of email patterns that decide who this policy matches. One pattern per line. Leave empty on the default policy — it’s the catch-all.

2. Sign-In Permissions

Three sub-tabs, one per policy-gated Sign-In module:

• Meeting Host — enable the Meeting Host flow for matched guests; configure the redirect URL, the default visit duration, and the maximum number of days a host can schedule a meeting in advance.
• Email Self-Provisioning — enable self-provisioning via email; configure device quotas, redirects for new / returning / verified guests, verification-mail behaviour, device-limit policy (allow, notify, or require approval), and session length (fixed timeout or a concrete end date).
• SAML Login — enable BYOD sign-in with SAML; configure the redirect, device quota, and session length (timeout or end date).

The remaining Sign-In modules (Quick Access, SMS, Radius, Password, Username & Password, Event Access, Blacklistings) aren’t gated by Access Policy — if the module is active at Context level, it is available to anyone who reaches the Captive Portal.

3. Self-Service Permissions

Two sub-tabs:

• Manage Conferences — allow matched Self-Service users to create and manage Conference-code sign-ins; configure the default conference URL, default and maximum conference length, and visitor limits.
• Manage Whitelistings — allow matched Self-Service users to whitelist devices by MAC address; configure the length policy (forever, a fixed number of days, or a calendar end date), maximum active entries, and calendar defaults.

The Self-Service Permissions tab is disabled when the policy’s master Self-Service Portal toggle is off.

Other permission pills

The policy list shows two additional Self-Service pills — Manage Guests and View My Devices — that don’t have their own toggle. They follow the master Self-Service Portal toggle: when it’s on, any guest who authenticates to the Self-Service Portal can view their own devices, and guests with the Meeting Host permission can manage invited guests.

A worked example

Suppose an Organization runs two audiences on one Sign-In Context:

• General guests — short visits, self-provision by email.
• Contractors — week-long engagements from a specific vendor domain, with SAML preferred.

Two policies cover this:

• default — no email pattern; Sign-In Permissions has Email Self-Provisioning on with a 4-hour session and a one-device quota.
• contractors — one email pattern matching the vendor domain; Sign-In Permissions has SAML Login on with a 5-day session and a two-device quota, plus Email Self-Provisioning as a fallback.

Both policies live in the same Context. The most-specific match wins; everyone else hits default.

Relationship to the rest of Sign In

• Policies are per-Context. Each Sign-In Context has its own set.
• A policy decides who can use which policy-gated module, and on what terms. Whether the module is active at all is decided at Context level on the module’s own page.
• Login events (signin.session.*) carry the policy that was evaluated — useful for auditing which policy granted access.