SaaS bugs often turn out to be corporate IT configuration issues. Whitelisting, security tools, and authentication services are to blame.
Software-as-a-Service is eating the world, and corporate IT departments are eating Software-as-a-Service.
Wait, what? I thought software was part of IT. Well, sort of. That means, not always. Uhm, it depends on which SaaS product we talk about.
Sometimes business functions procure SaaS products without involving their corporate IT. Sometimes corporate IT rolls out new security policies and products without informing SaaS providers. And sometimes corporate IT departments want to enforce their authentication standards, but they don’t want to help configure single-sign-on.
Do you think I am exaggerating? Here are some popular support ticket generation topics from my experience as the Founder & CEO of Yonder, a B2B SaaS company.
1. Whitelisting
Corporate IT departments often use whitelisting to avoid connections from the corporate network to untrusted internet addresses. While blacklisting blocks a set of specific internet addresses, whitelisting blocks everything that is not specifically allowed. That’s more secure but requires lots of communication with the software providers. Because it’s not just the website of your SaaS product that needs to be whitelisted, but also the sync gateways, the export service, or the authentication server behind your SaaS product.
Just as a SaaS provider, you do not know all the changes that are made in the corporate IT departments of your customers, your customers’ corporate IT departments don’t know the changes you made in your SaaS product. And whenever something doesn’t work for the end user, they think that the SaaS product has a bug. And they file a bug with the SaaS provider.
2. Security Products
IT security is getting ever more important, especially for critical industries such as finance, energy, aviation, or defense. Therefore, IT security constantly deploys new security products. Part of IT security is to keep quiet about the products in use to minimize the exposure to potential attackers and abusers. However, sometimes it’s required to share security products and their versions in use with key SaaS providers, as they cannot test or reproduce problems outside the customers’ network configuration.
The worst “bug” that we ever had in this respect was a customer who used an endpoint security product to control traffic at API level in their network. Our product can sync both content and user data between a web client and a mobile device for offline use. For this, we use several different APIs and endpoints within our application. The bug report said that the syncing of certain user data “sometimes doesn’t work.” After a detailed investigation, it turned out that “sometimes” referred to just one sync direction (mobile device back to web client) and sync operations within the customer’s corporate network in their headquarters. Because that customer is an airline, sync operations also happen in public WLANs all over the world, where synchronization worked properly. The root cause of the problem was that the endpoint security product blocked one of the APIs to sync user data, but just in one direction and just in the corporate network in their headquarters. And nobody told us about this new endpoint security product being rolled out.
Security products are also problematic without worldwide mobile sync operations. In another case, a customer couldn’t upload a certain file type to our system, claiming that this would delay an ongoing project. Our QA team managed to upload the file type to that customer’s tenant, so the “bug” was not reproducible. A screenshot of the network settings page from an affected end user at the customer revealed that their security product prevented the upload of the file type in question for security reasons. Neither the guys driving the project on the business side of this customer nor we as their SaaS provider knew about this security policy.
3. Authentication Services
Most of our enterprise customers want to use single-sign-on so that they can control access and authentication to a broad range of software applications. From my perspective, this is the best solution for enterprise customers, as they can control password length, 2-factor authentication, and session expiry themselves.
Unfortunately, some of our enterprise customers still don’t want to configure single-sign-on, even though they have well over 1,000 users. Therefore, those users still sign in with usernames and passwords, with the obvious consequences: Users forget their passwords, and often need to reset them.
A less obvious consequence is that in many large companies, the so-called U-number still exists: instead of using the email address as the username, the employee number is used as the username instead. So our monitoring systems often pick up failed login attempts, because users try to log in with their employee number instead of their email address. They think they have forgotten their password, but login fails because the username (i.e. the employee number) doesn’t exist in our system. They then try to reset their password, which is prevented from our side for security purposes: We don’t deliver emails after a certain number of failed login attempts to prevent penetration attempts. Of course, the affected end user doesn’t know that and files a bug ticket that the password reset email wasn’t delivered.
As A SaaS Provider, What Can You Do?
All the above examples are real-life examples, and not two enterprise customers have the same corporate IT setup. Therefore, it is impossible to standardize the non-functional IT requirements.
We have opted for a different path instead: Just like there is a knowledge base for end users, we are currently compiling an IT security guide and an IT operations guide for admin users. Those two documents should prevent apparent bugs as described in the real-life examples above, and through this increase the level of trust between the SaaS provider, the SaaS end users, and corporate IT departments.
