Introduction
Please note: this is a repost in the FSM Community from the original Developer blog.
ServiceNow Expert Services was asked to advise a customer implementing numerous Customer & Industry Workflow products onto their on-premise system. The problem statement was that they wanted to use the Agent mobile app for FSM (although the specific app does not matter to the problem) to enable field agents to work with their instance, however these devices were not managed by the customer themselves.
Because the devices were unmanaged, it was not possible to get them all to set up with a VPN to allow them entry into the network. The customer also did not want to provide them with "generic" internal network access, but only access to the instance. As a result, the connections would always be external - however, the on-premise instance was not exposed to the internet and therefore did not allow external access!
The predicament here is clear: unmanaged devices are always external, but the instance is network access-only. How can we provide users with access?
The out of the box solution
ServiceNow provides a great platform security solution called Adaptive authentication that satisfies this use case: it is a framework to enforce authentication policies such as IP filtering, specific roles, groups, trusted mobile apps, specific authentication methods, IdP attributes, etc.
The trusted mobile app functionality works by a one-time opt-in process from within the network, creating a whitelist for that device. The instance would be exposed to the internet but with the adaptive authentication layer, it would use a combination of an IP whitelist policy (to always allow all internal IPs) and the Whitelisted device policy. This would require those contractors to visit a customer location once to get access to the network, access the instance, go through the setup to whitelist their device, and then be able to access externally from that moment onwards.
Via this approach, the SN instance would technically be exposed to the internet but the adaptive authentication layer now still takes care of filtering external IPs on the app layer, instead of the network layer.
A recommended setup where the network gateway (load balancer, router, ...) exposes the SN instance to the internet and lets SN sort it out via Adaptive Authentication, but may redirect other requests to the firewall
However, our customer was opposed to this approach, clearly indicating that the SN instance would not be directly exposed to the internet under any circumstance, due to an unknown attack surface.
Our solution: giving control back to the customer
We came up with a solution that had the following premise:
- On the infrastructure layer, completely under the customer's control, they can build/set up an API gateway
- The agents will point their ServiceNow mobile app to this API gateway
- Any requests made to this gateway can follow some kind of validation logic to confirm whether the agent is already logged in and has a valid token (token introspection). If so, the request is allowed.
- Preferably, the validation logic and tokens are cached for the lifetime of the tokens, so that the introspection endpoint is not hit for every request
- We will whitelist a set of authentication endpoints
- Everything else is blacklisted
The customer felt more comfortable with this approach because they now fully control the list of endpoints and logic, and it is only their custom API gateway that is exposed, which is under their control.
There is a trade-off to this as well: with adaptive authentication, a ServiceNow platform security functionality is used, which is actively scanned and maintained by a team within SN. It is a productized feature that is well-supported and maintained. With this custom API gateway, the ownership of this security sits with the customer, which means they must also take ownership of keeping it up to date, scanning it for vulnerabilities, sustaining knowledge around it, etc.
However, this was the way deemed desirable, so we moved forward with it.
Login-page whitelisting
The first thing to be enabled in the gateway was a list of pages to be whitelisted for authentication. We confirmed the use cases, which was SSO-driven. The IdP itself was outside of the network, so there was no problem there. We found our list of pages by sniffing the network traffic and came up with a list of pages like:
- /api/now/sg/pre_auth
- /oauth_auth.do
- /login_with_sso.dlo
- /auth_redirect.do
- /login.do
- /oauth_login.do
- /oauth_token.do
- /m.do
- ...and a number of others
Token introspection
Next up, we came up with some endpoints that could be used for token validation in case the user was logged in.
We identified that there are two different scenarios:
- JWT token which is used by the mobile app's native components to talk to various SN backends
- Cookies which are used when an embedded web view is opened in the mobile app
In theory, any endpoint can be used for either. On a platform level, both a JWT and a Cookie are allowed for authentication. However, we did not want to just use any arbitrary page that had some computing cost, so we made 2 custom pages:
- A new UI page: just returning a blank page on the Platform view but needing a valid user session
- A new scripted REST endpoint: it did nothing, but we configured it to need a valid user session
The UI page returns 200 OK in case of a valid session or 301 Redirect (to /login.do) in case of lack of session, and the REST endpoint returned 200 OK or 401 Unauthorized respectively.
Thus, only the header code needs to be read in order to understand if the user is logged in or not.
Finally, some caching was implemented on the gateway level for the lifespan of the token in order not to hit these introspection endpoints every request.
The result
In the end, the final solution was successfully built, tested, reworked and deployed. It works! The external users with their unmanaged devices could now talk to the instance from outside the network, while every request is controlled on the network layer and the app layer.
This is of course essentially what adaptive authentication also offers, but without exposing the entire SN instance to the internet. As a trade-off, a custom API gateway is now exposed to the internet that the customer will have to maintain.
At the end of the day, ServiceNow still strongly recommends using adaptive authentication for this use case. It offers much more flexibility and is actively maintained by ServiceNow as a platform security functionality, plus is ready to go with minor configuration.
However, this article outlines that essentially anything is possible to meet specific requirements. If after careful consideration this is still outlined as the path forward, I hope that this has been informative and inspiring for your own needs.
Thanks for reading!
