Opportunities and Challenges in Implementing IDaaS
Companies are adopting a growing number of SaaS applications, everything from CRM to file management, to enable greater productivity across many business functions. As larger numbers of apps are rolled out to business units or company wide, the need for identity management increases (i.e., how are new users granted access, how are they terminated, etc.).
Here comes Identity as a Service (IDaaS). IDaaS is a category that makes use of Security Assertion Markup Language (SAML), to enable trust relationships and manage identities. With SAML there is an identity provider (source of truth for the identity) and service provider (the application the user needs to access). The setup of a new service provider (i.e., new SAML relationship) requires an administrator of both the identity provider and service provider. This setup can take anywhere from one minute (easy web based tools) to weeks (Professional Services and Statement of Work required) depending on how well supported this is from the service provider. The technical portion is exchanging metadata and certificates from both parties to enable the trust relationship.
There are many IDaaS vendors such as Okta, OneLogin, Azure AD, etc. and Service Providers (any cloud based app, or on-premise app) that supports SAML, some examples are SalesForce, Dropbox, EchoSign, etc.
This might seem like a significant amount work just to manage identities, but here’s the value at the end of the road:
●A new employee starts, she has access to all her apps in a single dashboard and is productive on day one (instead of spending two to three weeks getting access to everything).
●An existing, long-tenured employee is leaving and you have to remove all access; one-click access removal is always better than a fire-drill
●A business unit wants to roll out a new app for everyone, what is the adoption rate if that app is ready-to-use on launch day, versus every user having to create an account and remember their new password?
In implementing IDaaS (full disclosure, we chose Okta), a couple lessons are learned, that is worth sharing
●This is a Tier 1 application. When initially working with a competing vendor, support responses took three days. That’s unacceptable. Ensure you have the highest-level of support and uptime.
●This is an impactful organizational change. This change will likely affect every user in your organization. There is a common saying in IT “no one sees your many successes, but your failures are very visible.” Over communication (prior, during and post rollout) and training is required.
●Start slow. Implementing a “big bang” (all users) approach is very disruptive in the beginning. Instead choose one or two applications that have a smaller user population to test user feedback and any exceptions that might appear. Early users will get comfortable and help their peers upon a broader rollout.
●Deploy in Parallel. Many applications have an ability to allow user authentication via multiple mechanisms (username and password, SAML, OpenID, etc.). In our experience the traditional username and password is deployed, then we added our identity provider to run alongside for a couple weeks, prior to hard-cutover to SAML only.
●The shared accounts will bite you. If everything was designed perfectly there would be no exceptions, no one-off’s etc. In reality, there are many. The most significant of which is shared accounts and service accounts. Shared accounts (those used by multiple human users) and service accounts (those used by applications). Even though from a security perspective SSO accounts should be tied to a single user, there are always exceptions, and having an ability in the platform (identity provider) to handle those exceptions is key. For example, if you enable multi-factor authentication for all users; you’ll have to craft policy exceptions for shared accounts.
●It’s John not jsmith. Naming conventions are important. Most companies have a standard naming convention, but if you don’t, prepare to do a significant amount of legwork to rollout IDaaS. For example, if your user has an application username of [email protected] and you deploy identity provider and have a standard naming mapping for John as [email protected], John won’t be able to access his app anymore. The project should include this one-time manual re-work for every application.
●Discovering your users. Ideally you know every user in your environment; some are very clear: employees, part-time employees, long term consultants, etc. However, as you get into the deployment, you may also you’ll discover a multitude of contractors previously unidentified, remote workers, partners, etc. Your team will have to enable these users, and you’ll have to plan for appropriate licensing.
In all, IDaaS delivers a lot of business value if the teams responsible for deployment can handle some of the challenges noted.
Mikhael Felker
Director, Information Security, The Honest Company