Disable local login i.e. login.do for non-admin users which have SSO enabled

Dinesh90
Tera Contributor

Hello ServiceNow Community,

 

I have a requirement to disable local login i.e. login.do for non-admin users which have SSO enabled.

Please help me with the solution to implement to restrict local login(login with username & password) that is login.do for non-admin users and allow admins and integration users to have local login.

 

I have SSO enabled in the instance already for the same we want to restrict users to use local login(login.do).

please help with solution to implement 

 

Thanks

23 REPLIES 23

Dinesh90
Tera Contributor

@Ankur Bawiskar , @Chaitanya ILCR , @GlideFather @Maik Skoddow , @Aniket Chavan 
please help leaders 😊

Aniket Chavan
Tera Sage
Tera Sage

Hello @Dinesh90 ,

 

it's a fairly common requirement in environments where SSO is enabled. Based on a similar use case discussed in the community (reference shared below), here’s a possible solution that you can explore:

 

Suggested Approach:

You can use Installation Exit to control access at the point of local login. Here's how:

  1. Navigate to: System Definition > Installation Exits

  2. In the list, search for records with names containing "login".

  3. You'll likely find a script like LoginServlet. Since you're already using SSO:

    • You can either inactivate the default SSO login record or better,

    • Duplicate it and then modify the script logic inside.

What to Change:

In the process() function of your custom script, use the following idea:

  • Get the user_name from the login request.

  • Query the sys_user_has_role table to check if the user has admin or any other specific allowed role (like an integration role).

  • If the user doesn't have those roles, call loginFailed() and return  login.failed.

This way, only admins and integration users will be allowed to log in via login.do, while others will be blocked even if they try.

⚠️ Note: I found this approach in a helpful thread shared by another expert (thanks to Ali for that). I haven’t implemented it personally, so I'd recommend testing it in a sub-prod or dev instance first.

Let me know how this works for you!


🔹 Please mark Correct if this solves your query, and 👍 Helpful if you found the response valuable.

 

Best regards,
Aniket Chavan
🏆 ServiceNow MVP 2025 | 🌟 ServiceNow Rising Star 2024

 

Hi @Aniket Chavan ,
Thanks for your reply !!

 

I have 2 installation exists in the system, with name "login", "MultiSSOLogin".

Installation exists- "MultiSSOLogin" overrides the "login" record.

 

the multissologin record is having the below script added.


gs.include("PrototypeServer");
gs.include("SSO_Helper");

var MultiSSOLogin = Class.create();
MultiSSOLogin.prototype = {
    initialize : function() {

    },

    process : function() {
        // the request is passed in as a global
        var userName = request.getParameter("user_name");
        var userPassword = request.getParameter("user_password");
        var user = GlideUser;
        if (GlideStringUtil.notNil(userName)) {
            SSO_Helper.debug("Logging using normal DB");
            var authed = user.authenticate(userName, userPassword);
            if (authed) {
                // it logined with normal DB creds in a multisso environment.
                request.getSession().setAttribute("glide.authenticate.multisso.login.method", "db");
                SSO_Helper.clearCookie(SNC.SSOUtils.SSOID());
                return user.getUser(userName);
            }
        }
        else if (SNC.AuthenticationHelper.isMutualAuth() ) {
            var userLoginName = user.authenticateMutualAuthToken();
            if (userLoginName != null) {
                SSO_Helper.clearCookie(SNC.SSOUtils.SSOID());
                return user.getUser(userLoginName);
            }
        }

        this.loginFailed();
        return "login.failed";
    },

    loginFailed : function() {
        var sysMessage = GlideSysMessage;
        var gs = GlideSession.get();
        if (request.getSession().getAttribute("glide.authenticate.local.login.method") == "certificate") {
            var message = sysMessage.format("cert_login_invalid");
            gs.addErrorMessage(message);
        } else if (GlideController.exists("glide.auth.policy.ui.error.message")) {
            var authPolicyError = GlideController.getGlobal("glide.auth.policy.ui.error.message");
            if (GlideStringUtil.notNil(authPolicyError)) {
                gs.addErrorMessage(sysMessage.format(authPolicyError));
            }
        } else {
            var message = sysMessage.format("login_invalid");
            gs.addErrorMessage(message);
        }
    }
}

My Query - Should I update this "multissologin" script or the "login" one with your suggestion ? I think the multisso one as it overrides the login one, will it be fine to update this multiSSO one as this OOTB ?

also please help me with the script sample you are suggesting to add in the above script, pls mention the code line or function name where I can add the new logic. It  will be helpful if you can modify the above script with your suggestion 

Dinesh90_0-1751557929274.png

 



Maik Skoddow
Tera Patron
Tera Patron

Hi @Dinesh90 

what's the issue? If users don't have a local password they cannot log in via "login.do". That's a simple truth and it does not require any changes.

Maik