The Problem: One Login to Rule Them All
Until now, Identity Provider configuration in ServiceNow has been instance-wide. Configure SSO with Okta or Azure AD, and every portal on the instance inherits that configuration. Every user, every portal, same redirect.
The pain points
Employee portals need corporate SSO via Okta or Azure AD — but vendor portals need a different IdP, or just local login.
Customer-facing portals (CSM, Vendor Risk) sometimes need local login only, even when SSO is active elsewhere on the instance.
The workaround? Customizing the Login widget per portal. It works, but it’s fragile, hard to maintain, and doesn’t scale.
The Solution: Portal-Specific Authentication
With the Australia release, authentication settings live directly on each Service Portal record. The Login widget dynamically renders the correct options based on what you configure — no customization required.
What’s new
Configure authentication per portal. Falls back to instance-wide settings when not enabled. Fully backward compatible.
Use Portal-Specific Authentication
Opt a portal into its own authentication configuration, independent of instance-wide settings.
Enable Local Login
Show or hide the username/password form on a per-portal basis.
Portal Identity Providers
Choose which IdPs appear as login options — one, multiple, or none.
Early Redirection
When only one IdP is configured, auto-redirect users — no intermediate screen.
How to Set It Up
Prerequisites
Install the Multi-Provider SSO plugin — com.snc.integration.sso.multi.installer
Enable Multi-Provider SSO by setting glide.authenticate.multisso.enabled to true
Create your Identity Provider records (e.g., Okta, Azure AD) and configure SAML or OIDC as needed
Step 1. Enable “Show as Login Option” on Your IdP Records
Open each Identity Provider record you want to make available for portal login. Check the “Show as Login option” checkbox. This makes the IdP eligible for selection on portal records.
Step 2. Configure Authentication on the Service Portal Record
Navigate to Service Portal > Portals and open the portal you want to configure. Enable “Use portal-specific authentication”, then set your local login preference and select your Identity Providers.
Step 3. Select Your Identity Providers
The Portal Identity Providers field is a GlideList — you can select multiple IdPs. Only IdPs with “Show as Login option” enabled will appear as choices.
What the Login Page Looks Like
The Login widget dynamically adapts to your configuration. Here are the two most common setups:
SSO Only — No Local Login
Disable local login and configure one or more IdPs. Users see only the external login buttons — clean and direct.
Local Login + Multiple IdPs
Enable both local login and multiple IdPs. Users get the full username/password form plus external login buttons below.
Single IdP with Early Redirection
When only one IdP is configured and “Enable early redirection” is checked, users are automatically redirected to that IdP’s login page — no intermediate screen at all.
Real-World Use Cases
Scenario 1
Corporate Employee Portal + External Vendor Portal
Your /esc employee portal uses Okta SSO with no local login. Your /svdp vendor portal uses PingIdentity. Both live on the same instance, each with its own login experience — zero customization.
Scenario 2
CSM Portal with Local Login Only
Your Customer Service Management portal serves external customers who don’t exist in your corporate IdP. Enable portal-specific authentication, turn on local login, leave Portal Identity Providers empty. Clean username/password form, unaffected by SSO elsewhere.
Scenario 3
Mixed Authentication for IT Support
Your internal IT portal offers both Okta SSO and local login as a fallback. Enable both options, select Okta as the portal IdP, and check “Enable local login.” Users choose their preferred method.
Things to Keep in Mind
Plugin required — Install com.snc.integration.sso.multi.installer and set glide.authenticate.multisso.enabled to true.
Backward compatible — Portals without portal-specific authentication enabled continue using instance-wide settings. Nothing breaks on upgrade.
Server-side enforcement — Authentication method enforcement happens server-side. This is a security configuration, not just a UI change.
No widget customization needed — The out-of-box Login widget handles everything dynamically. If you previously customized it for authentication, you may be able to revert to base.
Ready to Try It?
Portal-Specific Authentication in the Australia release eliminates widget-level customization for different login experiences across portals. It’s a clean, admin-configurable, out-of-box solution for a long-standing pain point.
If you manage multiple portals with different user populations, this feature is worth exploring as soon as Australia lands on your instance.
Have questions or feedback? Drop a comment below — I’d love to hear how you plan to use this.
