How to strictly restrict Portal access by Role?

[divyashah]

Hi Community,

I am working on a requirement to strictly isolate user access between two ServiceNow Portals based on roles.

Requirement Details:

• Partner users should only be able to access the Partner Portal (/partner)

• Employee users should only be able to access the Employee Center (/esc)

Current Configuration:

• Login redirection has been implemented using SPEntryPage, and users are correctly redirected to their respective portals after authentication.

Challenge:
While the redirection works as expected, users are still able to manually access unauthorized portals via direct URL manipulation (for example, a Partner user entering /esc in the browser).

Expectation:
I am looking to enforce strict access control at the portal level, such that:

• Unauthorized users are completely blocked from accessing the portal

• Access results in a server-side Access Denied or 404-style response

• The solution follows ServiceNow best practices and is secure and maintainable

Questions:

1. What is the recommended best practice in ServiceNow to restrict Service Portal access based on roles?

2. Is there a standard server-side mechanism to enforce this restriction rather than relying only on UI redirection?

3. Are there any OOB approaches (ACLs, portal configuration, or scripting) that should be preferred for this use case?

Any guidance or proven approach from real-world implementations would be highly appreciated.

Thank you.

[VANSHIKAMUK]

1) Page‑level authorization with roles (primary control)

• On each Service Portal page (sp_page), populate the Roles related list with the role that are required to view it.
  • For the Partner Portal pages, add a role like x_partner.user (or your equivalent).
  • For Employee Center (/esc) pages, add sn_hr_sp.hrsp_employee / sn_hr_core or your chosen employee role.
• When a user without the role hits the page URL, Service Portal won’t render it. Instead, it routes to the portal’s Access denied page (configurable per portal). That’s server‑side enforcement.

2) Configure “Access denied” and “Page not found” pages per portal

• In each sp_portal record:
  • Requires login: ✅ enabled.
  • Access denied page: point to a page that shows a clear 403‑style message to unauthorized users.
  • Page not found page: point to a page with a 404‑style message.
• These are server‑side outcomes—not just UI messages.

3) Enforce with ACLs (data‑level protection)

• Even if someone finds a way to call a widget or data source directly, the table/field ACLs must block them.
  • Lock down tables used by the Partner portal to x_partner.user (or group/role equivalents).
  • Lock down HR/ESC data to employee roles only (e.g., sn_hr_sp.hrsp_employee).

4) Widget, menu, and module roles (defense‑in‑depth)

• sp_widget: set Roles on widgets so they can’t execute server scripts for unauthorized users.
• sp_menu / sp_menu_item: add Roles to keep navigation from surfacing cross‑portal links.
• Catalogs, Categories, and Items: restrict with roles so they don’t render in the “wrong” portal even if a page is reachable.

5) Routing/layout guards (optional belt‑and‑suspenders)

• If you have a global layout widget (present on every page), you can add a server‑side guard that:
  • Checks the current portal vs. the user’s allowed audience and,
  • If mismatched, sets a flag to render an Access Denied fragment or route to the portal’s Access Denied page.
• Treat this as secondary; your primary controls should be sp_page roles + ACLs.

Addressing your questions directly

1) Best practice to restrict Service Portal access based on roles?
Use sp_page Roles to authorize pages (server‑side), backed by table/field ACLs for data. Keep page sets distinct per portal so role gating is absolute.

2) Is there a standard server‑side mechanism rather than UI redirection?
Yes. Service Portal page authorization is done server‑side via sp_page Roles. Unauthorized users do not get the page rendered; the request routes to the portal’s Access denied page. Complement with ACLs to protect data.

3) OOB approaches to prefer (ACLs, portal config, scripting)?

• OOB & preferred: sp_page Roles, ACLs, Portal → Access denied/Page not found configuration, widget/menu roles, catalog/KB role restrictions.
• Optional scripting: A global layout widget server script as an extra guard, but avoid making it your only control.

[Ankur Bawiskar]

@divyashah 

you are already redirecting but users can change browser URL and navigate and see

For this you can use this workaround

use custom UI script and Ajax to inform them and redirect them to CSM portal automatically.

for that check this

Solution: Redirecting Users to the CSM Portal Based on Roles in ServiceNow

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏