---
sourceDocument: Brazil Platform security
sourceDocumentLink: https://www.servicenow.com/docs/r/platform-security

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil Platform security

ft:clusterId :

    - psec

bundleId :

    - psec

workflow :

    - Platform


---

# Redirect single sign-on (SSO) logins

# Redirect single sign-on (SSO) logins {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Redirect single sign-on (SSO) logins

This feature enables ServiceNow customers to control user navigation during single sign-on (SSO) login flows by redirecting users to specific pages based on login success, failure, or logout events.
It allows customization of user experience when accessing the instance, providing alternative login portals or informational pages while maintaining access to local login if needed.
Show full answer Show less  

## Redirection Properties and Their Use

* **glide.authenticate.honor.ssorecord.failedrequirementredirect:** Redirects users who try to access private pages without SSO credentials, typically to a company login portal.
* **glide.authenticate.failedredirect:** Redirects users after a failed SSO login attempt, often to a public knowledge article or error page explaining the failure.
* **glide.authenticate.external.logoutredirect:** Redirects users upon logout, usually back to a company portal or logout confirmation page.
* **glide.authentication.external.disablelocallogin:** When set to true (default is false), it requires SSO credentials on the main login page, working together with the failedrequirementredirect property to enforce SSO login.

These properties help manage user access flow and enhance security by guiding users to appropriate pages based on their authentication status.

## Behavior Control Based on Installation Exit Values

The system uses specific return values to determine the redirection behavior:

* **failedmissingrequirement:** Indicates missing SSO credentials; redirects to the URL defined in `failedrequirementredirect` for credential collection.
* **failedauthentication:** Indicates invalid or locked-out user credentials; redirects to the URL defined in `failedredirect`.
* **\<userid\>:** Indicates successful authentication for the specified user ID.

## Restricting Local Login for Enhanced Security

To prevent local login when users must authenticate exclusively through SSO, it is recommended to assign random passwords to imported users. This measure ensures users cannot sign in locally even if local login is accessible.

For users imported via import sets, an `onBefore` transform script can generate and assign a random password automatically, enhancing security by disabling local password use.

## Practical Benefits for ServiceNow Customers

* Customize user login and logout experiences by redirecting to internal portals or information pages.
* Improve security by enforcing SSO login and optionally disabling local login.
* Provide helpful error pages for failed login attempts to assist users in resolving issues.
* Control access flow seamlessly without disabling existing local login capabilities unless explicitly configured.  
When SSO is enabled, you can redirect users to specific pages or direct users to login
locally.
For example, if a user attempts to go to `https://customerX.service-now.com`, an internal company portal can display instead of the default login page. Or, when a user logs out of an application, the browser can redirect them to a specific internal page. You can set redirection properties within the instance to ensure that users see an SSO login page rather than the default login page.  
Note:  
The following properties do not force SSO. The login.do page is still accessible and users can login to the system if they have a local password set.

## Redirection properties {#r_ForcingLoginViaSSOOnly__redirection_properties}

When a user logs out, or if there is a failed attempt to sign on using SSO, you can define where the user is taken next, such as a main portal page or a knowledge base article with SSO login information. Use the following properties to specify the URLs. If one of these properties does not exist in your instance, you can create the property.

glide.authenticate.honor.sso_record.failed_requirement_redirect
:   URL to redirect users when they attempt to access a page that is private (for
    example, to view an incident) and do not provide SSO credentials. The property is
    typically set to a customer's login portal (for example,
    `http://portal.companya.com/`).

glide.authenticate.failed_redirect
:   URL to redirect users after a failed SSO attempt. You can redirect to a public
    knowledge article that describes the error and has helpful links (for example,
    `http://portal.companya.com/error`).

glide.authenticate.external.logout_redirect
:   URL to redirect users after logging out, typically back to the portal that enabled
    the single sign-on log in (for example,
    `http://portal.companya.com/logout`).

glide.authentication.external.disable_local_login
:   When set to true, requires SSO credentials for the main login page. Defaults to false. This property needs to be used in conjunction with the
glide.authenticate.honor.sso_record.failed_requirement_redirect property.  
The following table shows the relationship between the Installation Exit return values, the properties, and the expected behavior.{#r_ForcingLoginViaSSOOnly__table_lqh_2xs_x4__entry__3}

| Return value | Property | Behavior |
|-|-|-|
| `failed_missing_requirement` | glide.authenticate.honor.sso_record.failed_requirement_redirect | When this value is returned, it indicates that the required SSO credentials are not present in the session. Login fails and the session is redirected to the URL specified by the property. This is usually the URL for the SSO provider where login is challenged and credentials are collected. |
| `failed_authentication` | glide.authenticate.failed_redirect | When this value is returned, it indicates that the supplied SSO credentials failed authentication, the user does not exist, or the user is locked out. Login fails and the session is redirected to the URL specified by the property. This is usually the URL for the SSO provider where login is challenged and credentials are collected. |
| `<`<var class="keyword varname">user_id</var>`>` | N/A | Login authorized for the user specified by \<<var class="keyword varname">user_id</var>\>. This value matches with the field name defined in the SSO property glide.authenticate.header.value ("the instance's field name to match against the incoming header") |
[Table 1. Forcing login using SSO only]

{#r_ForcingLoginViaSSOOnly__table_lqh_2xs_x4}

## Restricting local login

As a security precaution, you should do more than rely on redirection properties to prohibit logging in locally. If a user should never log in locally and will always be authenticated by your internal single sign-on system, then a random password should be assigned to each user that is imported into the instance. The random password is most easily set at the time of the user import. If the user data is imported into your system through an import set, you can create an onBefore transform script using the following code .

    var r  = new Packages. java. util. Random ( ) ;

     var str1  = Packages. java. lang. Long. toString (Packages. java. lang.
     Math. abs (r. nextLong ( ) ) , 36 ) ; var str2  = Packages. java. lang.
     Long. toString (Packages. java. lang. Math. abs (r. nextLong ( ) ) , 36
     ) ;

     var newPass  = str1  + str2 ;

    target. user_password = newPass ;

     //password now set to a random string like this:
     //qvm81zdrn7cwwylpvw94eebk


