Overview
"Adaptive Authentication" is a plugin that was released in Quebec but has stayed relatively hidden for the majority of developers.
Although ServiceNow Out-of-the-Box allows to whitelist/blacklist IP Addresses to ensure only users from within certain locations can log in in the instance, it does not provide an easy way to allow or block people belonging to specific groups or having specific roles from accessing the instance. For this reason, the "Adaptive Authentication" plugin becomes handy, since it allows not only to check these three aspects (IP, Roles, Groups) but also allows them to be mixed in complex conditions.
That doesn't mean an organisation has to rely on all of those three criteria, but it may become very useful to define specific criteria that couldn't be defined without the plugin.
A classic use case where this becomes quite useful is when an organisation plans their go-live. Before going live the Service Desk, Knowledge Managers, Change Manager, etc... need to access the instance to ensure the Knowledge Articles are available and up to date, the required Standard Changes are available, or even last checks can be performed, amongst other tasks. Without this plugin the easier way would be disabling all accounts coming from AD enabling only those that need to access. This is a potential solution, but it means either AD synchronisations must be stopped or a script needs to run just after them to keep disabling the accounts until the go-live happens. Specially for large organisations this may be tricky to achieve and may be risky if there are good reasons not to access before the go live.
This plugin allows to run a series of policies that check the defined filter criteria before and after a user logs in to ensure they are allowed.
Policies
The plugin comes with a series of "Policies" that are enabled plus two disabled ones that can be enabled if required. Policies are executed by the system if they are enabled and the property called "glide.authenticate.auth.policy.enabled" is set to true. This property can be found in "Adaptive Authentication > Authentication Policies > Properties". Bear in mind this property comes disabled OOB.
Once enabled, they will validate the conditions specified either prior to the user logging in (when the page is loaded) or when the user successfully logged in. Obviously, having a role or belonging to a group is something that can only be checked after logging in, but checking the IP Address a user is coming from can -and should- be done before.
Filter Criteria
These criteria allow to define the elements we will be paying attention to. However, we haven't yet defined if these are the whitelisted or blacklisted, that will be specified later. These can be based on IP, Role or Group of the user accessing.
Role Filter Criteria
For instance, some role filter criteria we could be interested in creating could be "Admin", "External", "Internal" or "Fulfiller":
This would allow us to include the criteria in the policies to -for instance- check that only "Internal" people can access, only "Fulfillers" can access or only "Admin" can access. These criteria require a condition inside where we can select the roles that are behind each of them:
The condition will be checked when the related Policy is, and it will return "true" or "false" depending on the user who logged in. We can then link the criteria against the Policy we want, but we will see that in the next section.
Group Filter Criteria
Another kind of Filter Criteria that we can define is based on Groups. For instance a criteria that defines both the "Service Desk & Customer Service Management" teams, or another criteria for the "Service Support" team separately.
Let's have a look at how the SD& CSM would look like. We are selecting two groups, but we could select as many as we need:
Linking Policies to Filter Criteria
Now that we have defined the required Criteria and we know about the OOB Policies we can use, let's see an example of the "Deny Access Policy" where we will be defining which users must be denied access. It is paramount to select the right inputs, where we define the parameters we will be using in our criteria. In this case both the "Fulfiller" and "Admin" criteria are used.
Then, from the "Policy Conditions" tab we can create a new record. That record could look like the one below:
It must be remembered that the Filter Criteria will return either "true" or "false". Therefore in the Policy Condition we must define "Fulfiller IS false AND Admin IS false" if we want to deny access to anyone not having those roles.
In this case, as we are in the "Deny Access Policy" Policy we are defining a blacklist, but we could go to the "Allow Access Policy" if we wanted to define a whitelist after the user has logged in, to the "Allow access pre-auth policy" if we wanted to define a whitelist before the user has logged in or to the "Global Blocking Policy" if we wanted to block not only interactive sessions -other policies are triggered with interactive sessions only- but also any non-interactive one.
Bear in mind an interactive session is triggered by a real user and a non-interactive one by an automated event (integration, email,...)
Finally, there are two disabled (OOB) policies for Step-Up MFA and Step-Down MFA in case these cases were required, although if your organisation uses SSO they are not useful. If you want to know more about how to configure MFA within the Adaptive Authentication plugin check out this article created by
Results
When a user tries to log in but they have been blocked by a Policy they will receive an error message. Unfortunately, in case the user is local, they will get a message saying their username login or password are wrong. That can be misleading but it will ensure the user doesn't get through.
From a property perspective it allows to return a 403 or 404 error to external platforms where 403 is the default HTTP Status code. Additionally, it allows to return a specific error message, which OOB is "Access Denied"
If this blog article was useful to you, please click on “Helpful”.
Other blog articles created by me:
- Automating SMS texts and phone calls with Notify
- Translating tickets out of the box using the Microsoft’s Azure translation services
- Avoiding time-consuming transactions being automatically cancelled
- How to give your scripts a beatiful aspect in KB articles
- What is the Data Certification Plugin and how can it be leveraged?
- Validating Service Catalog variables following the best practice
8 Comments
