Self-Service Portal authentication

The Self-Service Portal is what your end users — residents managing a Wireless Personal Network, hosts running a conference, Endpoint Manager for Cisco ISE delegated administrators looking after one Endpoint Identity Group, Sign-In Self-Service Users managing whitelistings or conferences — sign in to.

Open Selfservice Access Control → Authentication in the Organization left navigation. The Self Service Portal Authentication card lists the two methods, one row each, and lets you turn each one on or off. The configuration here is shared by every Service Context’s Self-Service Portal, and only an Organization Owner can change it (see Administrator roles).

Email Magic Link (default)

Passwordless sign-in via a one-click link the platform emails to the address the Self-Service User was invited under. It is on by default: the Email Magic Link row shows the badge Enabled next to a Disable button, and the row reads “Default passwordless login method with Email Magic Link is available via [your Organization]‘s Self Service Portal URL.”

The link is one-shot: click it, you land on the Self-Service Portal already authenticated, no password screen and no MFA prompt. The link’s validity period is set in Organization Settings → Self-Service Portal Settings as Mail Login Token Lifetime (default 300 seconds).

This is the right default for the kinds of audiences the Self-Service Portal serves: occasional users who don’t want to manage another password, who already prove control of their email through invitation, and whose access is already scoped tightly by each Service Context’s Self-Service User list.

Turning Email Magic Link off

Once every end user signs in through your IdP, you can make the Self-Service Portal SAML-only. The rule: Email Magic Link can be disabled only while a SAML 2.0 identity provider for the Self-Service Portal is enabled and configured — issuer, SSO URL and IdP certificate all set. Until then the Disable button is greyed out and the row adds “Email Magic Link can be disabled when SAML 2.0 is enabled and configured.” A change attempted without SAML in place is refused with “Email Magic Link can only be disabled when SAML 2.0 for the Self Service Portal is enabled and configured.” — nothing is saved and nothing is written to the Audit Log.

1. Enable and configure SAML 2.0 first

   Follow the SAML 2.0 section below, tick Enable SAML 2.0 Self Service Authentication and save. Have a test user sign in through the IdP before you continue; once the magic link is off, SAML is the only way in.

2. Open Selfservice Access Control → Authentication

   With SAML enabled and configured, the Disable button on the Email Magic Link row is active.

3. Click Disable and confirm

   The Disable Email Magic Link dialog spells out the consequence: “Users sign in to the Self Service Portal with SAML 2.0 only. Sign-in links already sent by email stop working.” Confirm. The toast “Email Magic Link disabled” appears, the badge switches to Disabled, and the row now reads “Sign-in links sent by email are not accepted for the Self Service Portal.”

What changes while Email Magic Link is off:

• The sign-in page is SAML-only. The email field, the Send Link button and the “or” separator are hidden; only the SAML button(s) remain.
• Links already sent are revoked. Any email sign-in link, including ones sent before the change, lands on “Sign-in with a link sent by email is turned off for this portal.” (shown in the portal’s languages).
• Platform emails point to the sign-in page instead. Emails that lead users to the portal — the EasyPSK member invitation, the sponsor request, the guest emails — link to the portal’s login page rather than carrying a one-click sign-in link.
• Your SAML 2.0 identity provider is locked in place. It cannot be disabled or deleted until Email Magic Link is back on (see SAML 2.0 below).
• The change is audited. The Audit Log records an UPDATE row, “Organization Self-Service Email Login updated”.

This is one setting per Organization, and it governs every sign-in to that Organization’s Self-Service Portal — EasyPSK residents, Sign-In Self-Service Users, conference hosts, Endpoint Manager delegated administrators and sponsors alike. It does not change Captive Portal sign-in.

Turning it back on

Enabling Email Magic Link again is always allowed. Click Enable on the row and confirm in the Enable Email Magic Link dialog (“Users can sign in to the Self Service Portal with a link sent to their email address.”). The toast “Email Magic Link enabled” confirms it, the badge returns to Enabled, the sign-in page shows the email field again, and users request a fresh link as usual. This change is audited the same way.

SAML 2.0

With SAML 2.0, end users (residents, group administrators, conference hosts) sign in to the Self-Service Portal with their account in your identity provider (IdP). Click Enable on the SAML 2.0 row to open the configuration page.

The configuration page is the same as for the Admin Portal, and is described field by field in SAML configuration. What is specific to the Self-Service Portal:

• A separate application in your IdP. The Self-Service configuration has its own Entity ID and Reply URL, so register it as a second application next to the Admin Portal one.
• No roles. There is no Default Role Mapping. SAML proves who the user is; what they can see is decided in each Service Context. See Self-Service Portal access.
• Also used by the Captive Portal. Sign-In Contexts with the SAML SSO module sign guests in through this configuration (see the note at the end of this page).
• Turning it on. The switch is Enable SAML 2.0 Self Service Authentication in section 5. While Email Magic Link is disabled, a hint under the switch reads “Email Magic Link is disabled, so SAML 2.0 is the only sign-in method for the Self Service Portal. Enable Email Magic Link before you disable SAML 2.0.”

How the sign-in works, and the IdP setup, are described in How SAML works and Microsoft Entra ID.

While Email Magic Link is off

With the magic link disabled, this identity provider is the only way into the Self-Service Portal, so the platform won’t let you disable or delete it. Either action is refused with “This identity provider is the only sign-in method for the Self Service Portal while Email Magic Link is disabled. Enable Email Magic Link first.” Turn Email Magic Link back on, then change SAML. The one exception is an identity provider whose configuration is incomplete — it is already unusable for sign-in, so it can still be edited or deleted to be repaired.

Running both methods at the same time

Email Magic Link and SAML 2.0 can be enabled together. When both are on, the Self-Service Portal sign-in page presents both options to the user. Email Magic Link continues to work for any Self-Service User regardless of whether they are in your IdP; SAML works for users who are.

This is the gentlest migration path: enable SAML alongside the default magic link, communicate the new option to Self-Service Users, and confirm every end user is reachable through your IdP. Then go SAML-only by clicking Disable on the Email Magic Link row, as described under Turning Email Magic Link off. From that point the sign-in page shows only the SAML button(s), links already sent by email stop working, and the SAML configuration is locked until you turn the magic link back on.

Warning

If SAML 2.0 later becomes unusable for some other reason — for example because the configuration that carries it is removed or moved — the Email Magic Link setting stays off and nobody can sign in to the Self-Service Portal. The Admin Portal shows the warning Self Service Portal sign-in unavailable: “Email Magic Link is disabled and no SAML 2.0 identity provider is enabled and configured, so users cannot sign in to the Self Service Portal. Enable Email Magic Link, or enable and configure SAML 2.0.” End users see “Sign-in to this portal is not available. Contact your administrator.” on the sign-in page. Enable Email Magic Link (always allowed) or restore the SAML 2.0 configuration to bring the portal back.

What this configuration is not

• Not the place to grant Self-Service access. Inviting a resident to a Wireless Personal Network, a delegated admin to an Endpoint Identity Group, or a host to a conference is done inside each Service Context’s own Self-Service Users tab. SAML here only changes how they sign in once they’ve been invited.
• Not shared with the Admin Portal. Configuring SAML for the Self-Service Portal does not federate the Admin Portal. See Admin Portal authentication for that — it’s a separate SP endpoint, separate IdP application.

Note

Also used by the Captive Portal SAML Sign-In Module. Sign-In Contexts that publish a SAML Login Module on a Captive Portal reuse this Self-Service Portal SAML configuration as the underlying federation. If you change the certificate or IdP URL here, the Sign-In Module’s SAML logins follow. See Sign In SAML SSO module.