Feb 20, 2024
Table of contents
For the modern CISO, there can be a near-constant pressure to support staff productivity. But doing that in a controlled and secure way is a challenge, especially when users are demanding an ever-increasing number of applications at work. Managing secure and compliant access to these SaaS apps, user provisioning, and user deprovisioning in a streamlined manner lie at the heart of the challenge.
Fortunately, there are ways to achieve this — via single sign-on (SSO), SAML, and SCIM. But as the CISOs AccessOwl co-founder Philip Eller spoke to confirm, there are numerous roadblocks in the way of the practical use of such features.
Why companies need SCIM and SAML
System for Cross-domain Identity Management (SCIM) is an open standard designed to automate user provisioning and deprovisioning across domains — eliminating the need for expensive custom integrations or for managing proprietary APIs. Security Assertion Markup Language (SAML) is another open standard; this one allows identity providers to exchange authorization credentials with service providers. In doing so, it supports SSO to enhance the end user experience and reduce the corporate digital attack surface.
Julie Goyen, Director of Cloud and Infrastructure at Worksoft, explains that wherever she has worked, there has always been a drive to get “as much SSO with provisioning as possible” in corporate applications.
“When we’re out purchasing software, we’re asking, ‘Does it have SCIM or SAML?’ and if it does, great. Let’s try and leverage that because then we can create a security group and add people to that group. As they leave, we can remove all the groups that they’re in, so it will cut off their access,” she says.
However, Goyen adds that because not every piece of commercial software supports these capabilities, difficult decisions have to be made about whether to purchase a particular app or not.
“It may mean the surface attack area grows while the IT team is getting smaller, because to management IT, staff is viewed as an overhead,” she adds.
Partly for this reason, managing who has access to what in the organization is still a large amount of manual work for Goyen and her team. This work is important for SOC2 compliance but can take its toll, she says:
“If you don’t do it because it’s mind-numbing, and then nobody does it, it just grows to this great big behemoth that somebody has to go through and fix.”
Coveo Team Lead for R&D Security Defense Jean-Philippe Lachance says that when there are apps that don’t support SCIM, he connects programmatically using APIs. However, once again this entails a significant development effort.
“Using APIs and some Python code, we connect to that system, we list all the users, we list all the permissions of those users, and then we compare to a manifest, listing what a member of a specific group should have access to,” he explains. “So we do pretty much exactly what SCIM is doing. Then the code applies the required fixes. We add missing privileges, we remove privileges that should not be there — and the code does that three times per day.”
Lachance says his team deliberately chooses only tools featuring SCIM or dedicated APIs like this. But he adds that the company’s corporate IT department is put in a tough situation because many of the apps it supports don’t even have API connectivity, for managing provisioning and access manually.
The burden of an SSO tax
All of which helps to explain why SCIM, SAML and SSO have become so important to stretched IT teams looking to drive security, usability, and compliance. But there’s another hurdle. It’s not just that SCIM and SAML aren’t supported in certain applications. Increasingly, these capabilities are featured only in enterprise-level versions of applications, which means that organizations must, in some cases, pay two to four times the base product price simply to use SCIM and SSO. This is sometimes described as the “SSO Tax”, and it’s a growing source of irritation and pain for many security leaders.
Intercom Director of IT Emanuel Sparvoli says that SSO is so important that he will purchase apps only if they support it.
“If you’re building a SaaS app and you don’t have some form of SSO, you don’t care about your customers’ data,” he explains. “SSO as a feature should also be free because any company with more than a handful of employees should use an identity provider and applications that support SSO.”
However, he rails against SaaS vendor attitudes that imply that smaller firms don’t need to spend as much time and effort on security, and therefore that SSO, SCIM, and SAML should be considered enterprise features.
“Somehow, there’s this belief in part of the industry that because you don’t have thousands of employees, then your threat modeling shouldn’t be that complex. How many times have I heard that we are a small company, so we don’t need to spend that much time on security?” he asks. “But it’s so hard as a small company to gain a reputation as a product that you can trust. It takes one simple incident to lose all that trust you gained.”
Getaround CISO Mel Reyes agrees, revealing that he has lost sleep over the high charges the SSO tax places on small firms.
“You don’t get SSO, you don’t get SAML, and you don’t get SCIM, unless you pay four to 20 times the user base cost. And you suffer. You suffer with having to continue to do things manually,” he says. “I don’t have seven digits just to get some of the core fundamental things that should be part of a secure platform anyway.”
TSC Security Managing Partner Dave Anderson explains that the barriers put in his way by the SSO tax made it extremely difficult to transition to a passwordless environment. Like many of the other CISOs we spoke to, he found that it added significant extra manual work. It meant complex, time-consuming quarterly access reviews during which an IT admin or application owner was forced to log into each app on a dedicated SaaS catalog and review permissions for each user.
“We had this huge off-boarding checklist, which was ridiculous. We just had to remove people from all these different applications manually because … we didn’t pay the SSO tax,” he explains. “There were just so many apps that it didn’t make sense for us to get the enterprise version. We didn’t need all the features. And it didn’t really justify spending two to four times what we were already spending.”
Time for a rethink
Anderson urges SaaS vendors to rethink their business models.
“That’s one of those things that just irks me about a lot of SaaS companies. Just dial things back a little bit and think this through. If you want to charge for SSO, I don’t have a problem with that. But don’t make me upgrade to your most expensive product,” he urges. “Charge me, to start, $500 a month, or charge me maybe $2,000 for implementation or something like that.”
Startup security teams are struggling to cope with the manual work the SSO tax is forcing them to undertake, which is bad news for the bottom line, and potentially their risk exposure.
“Security teams and IT teams are just too small. It was always my number one challenge — to get the amount of staff that I really needed to be able to do everything that I wanted to get done,” Anderson explains. “Everything at that point just ended up being negotiation and sacrificing one thing for another.”
To navigate this dilemma, Tobias Klingel, Aspire’s Head of Infosecurity, suggests adopting a more budget-friendly approach to manually manage provisioning and deprovisioning. This strategy, while cost-effective, introduces significant risks, including the potential oversight of critical deprovisioning tasks.
“In the past, we often bought software in an enterprise plan to have access to SSO. But then our investors turned almost 180 degrees, and we looked at where we could save money,” he explains. “We actually hired some people in Asia to do all that work manually.”
Of course, aside from the potential for human error to creep into provisioning processes, it’s not an approach that many small companies could copy.