And in the case of passwords, each one – especially each forgotten one – is a little security risk scurrying around in the shadows. You may think you have gotten rid of them (or at least reduced them to a manageable amount), but they still keep popping up. And as we all know, SaaS applications, whether they’re personal or social apps like Facebook or the thousands of business apps in use today, have caused this problem to, well…multiply rapidly.
The single biggest reason identity-management-as-a-service (IDaaS) offerings such as Azure Active Directory, Okta, and others are popular today is because they provide single sign on (SSO) to SaaS apps from a user’s browser. They also provide increased security by managing these userids and passwords. The user simply accesses a company portal that has icons representing the apps, and clicks on an icon to login.
Though this capability is an improvement over an unmanaged login, there are still significant security risks you need to know about.
SaaS Password Wrangling: Vaulting and Replay
First, a little background on how IDaaS applications handle website credentials.
The largest and most popular business SaaS apps today such as Salesforce, Workday, Concur, and several hundred other support identity federation, which both dramatically simplifies logging in to an app and increases its security. However, the vast majority of SaaS apps on the market require a userid and password to login from the user’s browser – a messy business fraught with forgotten passwords, too-simple passwords, and sticky pads with written-down passwords.
IDaaS services use two main techniques to take care of this for the user. First, when a user initially logs in to one of these “form fill” sites, a password capture extension in their browser asks if they’d like to store their credentials in the IDaaS’ service’s password vault. Second, the next time the user wants to logon to the SaaS app, the browser extension communicates with the IDaaS service to replay the user’s credentials into the userid and password fields, thus logging them on without any action on the user’s part.
The Passwords That Got Away
Password vaulting greatly simplifies logging on to these apps, especially compared to the user trying to keep track of it all themselves. But it’s a chewing-gum-and-bailing-wire approach to security for five reasons.
- First, it means the user’s credentials are stored in the IDaaS provider’s cloud service, which is a no-no for many company’s IT security policies.
- Second, no matter how encrypted the creds are when in the cloud, they must be transmitted in the clear to the SaaS app during the replay process. There’s no way around it. Third, app user login pages change layouts all the time, so the IDaaS provider must attempt to stay current with thousands of these changes so the password replay works correctly.
- Fourth, in most circumstances the user knows their userid and password for the app. (They certainly did before they were required to access the app through the company’s user portal.) This means they can always perform an end run around the portal and login directly. If it’s a new app going into service, some IDaaS providers support the admin uploading the user’s credentials for them so the user doesn’t know it and thus must use the portal – but this only works for onboarding new apps. Some IDaaS providers have a limited ability to change the password for a few apps, and some can obfuscate the app’s login URL, but those are a tiny minority. To make the situation worse, browsers like Chrome or browser add-ins like LastPass handily offer to save the user’s password when they login. And why wouldn’t the average user want to store the password so they wouldn’t have to enter it again?
Finally and most importantly, the SaaS apps aren’t tied into the corporate identity lifecycle management system. What does this mean? It means that if you terminate an employee and disable their account in their on-premises AD DS, the user can no longer login to the corp network or access its resources. When that disablement replicates up to the IDaaS service, the user can’t access any cloud resources that require the IDaaS service such as federated apps (Salesforce, Office 365). This is goodness and makes the security people happy.
But form fill SaaS applications don’t depend upon your corporate credentials like federated SaaS apps do. When that AD DS user account is disabled or deleted, nothing happens out at that SaaS app. It has no idea what’s happened back at the company. Unless someone takes the explicit action to audit what apps the user has access to, and manually disables them at every app, the user can get in. Why? All the user needs is their userid, password, and the login URL of the app.
I should point out that these issues aren’t the IDaaS provider’s fault; they’re doing the best they can, using various smoke-and-mirror techniques, to smooth over the inherent failings of the form-fill SaaS app login scenario.
To summarize; Provisioning users to applications is relatively straightforward. De-provisioning them is another matter entirely.
What Organizations Can Do
This is an issue that’s extremely difficult to fix retroactively. Instead, you must get in front of it:
- Audit the SaaS apps a user has access to, stored in a centralized entitlements database so you know what everyone has access to. This is much more of a policy and process problem than it is a technology problem.
- Use Group Policy to disable the Chrome password manager.
- When possible, use an option to automatically generate and vault the user’s password so they don’t’ know it.
- When your organization is evaluating SaaS apps, federated login should be a requirement – not a “nice to have”. Make sure the ISV knows this. Only customer requirements (i.e. sales) drive ISVs to make changes.
IDaaS providers can be a great benefit to your users by providing SSO to many SaaS applications through a single user portal and multiple form factors. They’re also a great benefit to information security because it provides some degree of centralized management to these apps. But you still need to take steps to make it a secure solution.
