Disable local login i.e. login.do for non-admin users which have SSO enabled
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-03-2025 07:03 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-03-2025 07:18 AM
@Ankur Bawiskar , @Chaitanya ILCR , @GlideFather @Maik Skoddow , @Aniket Chavan
please help leaders 😊
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-03-2025 07:30 AM
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:
-
Navigate to: System Definition > Installation Exits
-
In the list, search for records with names containing "login".
-
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-03-2025 08:52 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-03-2025 08:31 AM
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