Skip to main content
SAML SSO — labelled SAML Logins in the admin — lets guests sign in to the Captive Portal using their existing corporate or Organization account instead of creating a new credential. Captive Portal SAML uses the Organization’s Self-Service identity provider (configured once under Organization → Accounts → Federation). The same IdP that lets your colleagues sign in to the Self-Service Portal also lets them sign in through the Captive Portal on any Sign-In Context where the module is enabled. Who actually gets through is decided by the Context’s Access Policy — see below.
SAML Logins module admin page

​
How a guest signs in

  1. The guest picks SAML on the Captive Portal.
  2. Their browser is redirected to the Organization’s Self-Service IdP.
  3. After IdP authentication, the browser returns to the portal with a signed SAML assertion.
  4. Netgraph validates the assertion, then consults the Access Policy for this Context. The policy decides whether this identity is allowed through.
  5. If allowed, network access is granted.

​
Who gets through: Access Policy filtering

Authentication and authorization are separate:
  • Authentication — “is this person’s IdP account valid?” — handled by the Self-Service IdP.
  • Authorization — “should this authenticated person get access on this Context’s Captive Portal?” — handled by the Access Policy.
A Captive Portal SAML sign-in only succeeds when both line up. On each policy’s Sign-In Permissions → SAML Login sub-tab:
  • SAML Login — master flag. Must be on for SAML to appear on the portal for guests matched by this policy.
  • Max devices — per-identity device cap.
  • Redirect — where the guest lands after a successful SAML sign-in.
  • Session length — a fixed timeout or a concrete end date. Only the flag chosen on Ticket policy is used — the other field is ignored.
Which SAML identities a policy catches in the first place is governed by the policy’s Applies To email patterns. For example, a policy with @your-company.example on Applies To only accepts SAML identities with that email-domain suffix. See Access Policies for how to decide which policy a given guest matches.

​
Activate the module on the Context

Prerequisite: the Organization has a Self-Service IdP configured (see Organization SAML authentication). Without that, the Captive Portal SAML module has nothing to authenticate against.
1

Open the module

Sign In Modules → SAML Logins inside the Sign-In Context.
2

Activate

Click Activate SAML Users Login Module. The module is now available to Access Policies.
3

Enable SAML provisioning in the relevant Access Policy

Captive Portal → Access Policies → the policy you want SAML on → turn on the SAML provisioning flag. This is the switch without which SAML will never appear on the portal for guests matched by this policy.
4

Configure walled-garden entries

Guests’ browsers must reach the IdP before sign-in completes. Add the IdP’s hostnames to the Captive Portal walled garden — see the IdP setup guide for the specific hostnames per IdP.
5

Test with a non-admin account

Sign in as a regular user from a clean browser session. Confirm the round-trip completes and a login appears in the Context’s Dashboard.

​
Managing SAML guests

The main tab lists SAML-authenticated guests by email with last login, total logins, and device counts.
  • Filter by email.
  • Revoke a guest — future sign-ins require another SAML round-trip (and still have to pass the Access Policy).

​
Compared to Organization-Admin SAML

Two separate configurations live under Organization → Accounts → Federation:
TargetAudienceUsed for
Admin PortalOrganization administratorsSigning in to the Admin Dashboard
Self ServiceOrganization’s end usersSelf-Service Portal and Captive Portal SAML
A change to the Admin Portal IdP never affects guest Captive Portal sign-in, and vice versa.

​
MFA in the Captive Portal

Multi-factor prompts can be difficult during Captive-Portal sign-in — many devices restrict multitasking while captive, so the guest can’t easily open an authenticator app. If MFA becomes a blocker, your IdP may support conditional policies that skip MFA specifically for the Captive Portal application. See SAML IdP setup → disabling MFA for the Captive Portal.

Organization SAML authentication

Where the Self-Service IdP is configured.

SAML IdP setup

Concrete walkthroughs for Azure, Google, Okta.

Access Policies

Where SAML provisioning is enabled and users are filtered.

Walled garden

Pre-auth reachability for the IdP hostnames.