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.

[divyashah · Accepted solution]

[SOLVED] Workaround: Restricting Manual URL Access to Portals using a Header Widget

Post Body:

Thanks @VANSHIKAMUKand @Ankur Bawiskar for your detailed responses and guidance.

The Challenge:

While SPEntryPage successfully handled the initial login redirection, I faced an issue where users could still access unauthorized portals by manually typing the URL (e.g., a Partner user typing /esc).

The Constraint:

As @VANSHIKAMUK mentioned, the standard OOB method is using User Criteria (Can View/Cannot View related lists) on the Portal record. However, in my specific instance, the Service Portal User Criteria Support plugin was not active, and I did not have the permissions/access to enable the specific system properties to expose those related lists.

The Solution (Workaround):

I implemented a "Security Guard" logic directly within the Portal Header. Since the header loads on every page, it acts as a gatekeeper. If an unauthorized user tries to force their way in via URL, the header script detects their role and immediately redirects them back to their allowed portal.

Here is the implementation steps for anyone facing similar constraints:

Step 1: Create a new Widget

• Name: Portal Security Redirect

• ID: portal-security-redirect

Server Script:

JavaScript

(function() {
    var user = gs.getUser();
    var portal = $sp.getPortalRecord().url_suffix.toString(); 
    
    data.redirect = false;
    data.redirect_url = "";

    // SCENARIO 1: Partner User trying to access Employee Center (/esc)
    // Check if user is a Partner (and NOT an Admin)
    var isPartner = user.hasRole('partner_user') || user.hasRole('partner_mgmt_user');

    if (portal == 'esc' && isPartner) {
        if (!user.hasRole('admin')) {
            data.redirect = true;
            data.redirect_url = '/partner'; // Route back to Partner Portal
        }
    }

    // SCENARIO 2: Internal Employee trying to access Partner Portal (/partner)
    if (portal == 'partner') {
        // If they are NOT a partner and NOT an admin, don't allow them 
        if (!isPartner && !user.hasRole('admin')) {
            data.redirect = true;
            data.redirect_url = '/esc'; // Route back to Employee Center
        }
    }
})();

Client Controller:

JavaScript

api.controller = function($window) {
  var c = this;
  if (c.data.redirect) {
      $window.location.href = c.data.redirect_url;
  }
};

Step 2: Embed this Widget in your Portal Header

I opened my custom Header widget (used by the Portal Theme) and added the security widget to the very top.

• Header Widget Server Script:

  data.securityRedirect = $sp.getWidget('portal-security-redirect');

• Header Widget HTML Template (at the very top):

  <sp-widget widget="data.securityRedirect"></sp-widget>

This successfully blocks manual URL manipulation without requiring the User Criteria plugin. Thanks again for the help!

[Ankur Bawiskar · Accepted solution]

@divyashah 

I believe I also shared a working solution using UI script.

Thank you for marking my response as helpful.

💡 If my response helped, please mark it as correct ✅ as well so that this helps future readers find the solution faster! 🙏