Aller au contenu

Captive portal flows

A flow is one way through a captive portal: the questions a visitor answers and the conditions they must meet before their device is placed in the flow’s target endpoint group. A portal offers up to four, one of each type, on a single landing page, or opens straight into one of them (Default Flow on the General tab).

TermMeaning
Guest AccessTemporary access for visitors, self-service or approved by a sponsor, optionally with an email or SMS code.
Self RegistrationVisitors sign themselves up with a verified email address or phone number. No sponsor is involved.
BYODA person with a Taranac account enrols a personal device with their credentials.
Accept Use PolicyThe lightest flow: show a policy, tick “I agree”, get access.
Target Endpoint GroupWhere the device lands when the flow completes. Required on every enabled flow: saving the portal is refused without one.
SponsorA Taranac user who approves a guest’s request from an emailed link.

Every flow card on the Flows tab has a display name, an icon, an order, an enable switch and a Target Endpoint Group. The settings below are the rest of the card. On a standalone portal that opens access itself, each flow also has a Speed limit for this flow. See speed limits.

Temporary access for visitors. The guest fills in a form (name, email, and optionally phone, company and reason for visit) and gets access either immediately or after a sponsor approves.

SettingValuesNotes
Access ModeSelf-service / Sponsor requiredSelf-service grants access on completion. Sponsor required holds the session until an employee approves.
Verification MethodNone / Email / SMS / Email or SMSSends a one-time code, which the guest must enter before access is granted.
Verification Code TTL (minutes)10How long the code stays valid.
Registration Fieldsper field: Required / Optional / HiddenName, Email, Phone, Company, Reason for visit.
Session Duration (hours)240 means no expiry.
Max Devices per Guest1
Require terms acceptanceoffShows a terms text the guest must accept.
Sponsor ModeGuest chooses sponsor / Fixed sponsorWith a sponsor required, either the guest types a sponsor’s email address, or every request goes to one user you pick.

With sponsor approval, the guest’s session waits as Pending Sponsor and the sponsor is emailed an approve/reject link. There is no sponsor inbox in the admin console; approval happens from the email. The sponsor’s address must belong to an active Taranac user. An unknown address is refused when the guest registers, so the guest is never left waiting for someone who will never be asked. On approval the device is placed in the target group and access is opened. If a verification code is also required, the sponsor is notified only after the guest has entered it.

An administrator can also approve or reject a waiting session from Guest Sessions. That is recorded as an approval by an administrator, and it skips both verification and the sponsor.

Visitors sign themselves up with a verified contact address. No employee has to vouch for them, and no credentials are needed. Verification is mandatory: the form offers Email, SMS and Email or SMS, and no None. Otherwise it works like the guest flow without a sponsor: once the code is entered, the session becomes active and the endpoint joins the target group.

No portal flow creates a Taranac user account. Portals register devices and issue guest sessions; lasting accounts are created under Identity → Users. To limit who may register, use the portal-wide allowed and blocked email domains on the Security tab.

SettingValuesNotes
Verification MethodEmail / SMS / Email or SMSAlways required.
Verification Code TTL (minutes)10
Registration FieldsRequired / Optional / HiddenThe same five fields as Guest Access.
Session Duration (hours)240 means no expiry.
Require terms acceptanceoff

A person with a Taranac account registers a personal device. They enter their credentials and accept the terms; Taranac authenticates them, binds the device’s MAC address to their account and opens access.

SettingValuesNotes
Authentication MethodBoth (Local & LDAP) / Local / LDAPWhich identity source is accepted. The source is checked before the password, so a login from the wrong source is rejected without revealing whether the credentials were valid.
Require multi-factor authenticationoffA portal-level requirement, independent of any group’s MFA policy. A user without an MFA provider is asked to set one up in the main portal.
Access ModePermanent / Time-limitedPermanent binds the device with no expiry and creates no guest session. Time-limited creates a session that expires.
Session Duration (hours)24For time-limited access; 0 means no expiry.
Max Devices per User3
Require terms acceptanceon

The user must already exist in Taranac: the portal registers devices, it does not create accounts. An expired password, or one that must be changed, is rejected with a message telling the user to change it in the main portal. A device whose endpoint is blocked is refused through every flow.

Show a policy, optionally require an “I agree” checkbox, and open access. No credentials and no registration form.

SettingDefaultNotes
Require “I agree” checkboxonThe user must tick it to continue.
Session Duration (minutes)480 (8 hours)0 means no expiry.
Terms TexttemplateThe policy text. It ships with a ready-made Permitted Use / Prohibited Activities / Monitoring template.

On acceptance, Taranac records that the endpoint accepted the policy, joins it to the target group and opens access. If the device’s MAC already has an active AUP session, that session is reused instead of creating a second one.

You want to…Use
Let visitors get temporary access themselves, optionally with an email or SMS codeGuest Access (Self-service)
Have an employee vouch for each visitorGuest Access (Sponsor required)
Let staff enrol their own phones and laptops with their existing accountBYOD
Let visitors sign themselves up, but only with a verified email or phoneSelf Registration
Only make everyone accept a usage policy before getting on the networkAccept Use Policy

Flows can be combined on one portal. A common landing page offers Guest Access for visitors and BYOD for staff, with a different target group for each, so your policy can treat them differently.