“What happens on your iPhone, stays on your iPhone.”
That’s the text from a billboard ad Apple placed outside last year’s Consumer Electronics Show in Las Vegas. The words are tongue-in-cheek, but the message is clear: Consumers want their data protected.
Unfortunately, protecting data is getting harder. Companies are moving their data storage and software hosting from on-premise systems to cloud-based ones, introducing security vulnerabilities that weren’t there before.
At the same time, wide-reaching privacy regulations like the European Union’s General Data Protection Regulation and the California Consumer Privacy Act create more stringent requirements for app developers and enterprises. These companies are left with a choice: invest time and money in beefed-up security systems, or risk big fines and bad press.
What is an identity management system?
Austin-based SailPoint is one such security system. SailPoint specializes in identity management systems and technologies, which organizations use to authenticate users and manage what data and applications each person can access.
“Now, more people call it ‘identity governance,’” SailPoint senior security strategist Mike Kiser said. “That better expresses the value it is to the organization. It’s not just managing IP addresses and creating accounts, which is nice. It’s enhancing productivity. It’s certifying you’re doing due diligence to protect your resources and data, which is massively important.”
Every identity management system has three main components, Kiser said.
First, there’s a data repository where the organization can efficiently store and retrieve information about its environment and users. Second, there’s an identity tool that compiles a user’s accounts, access and attributes. Third, there’s a policy engine that determines if a user’s level of access matches what’s allowed for their identity.
Beyond these building blocks, identity management systems are highly complex — and very much in flux. As new threats emerge, new layers are added, and identity paradigms are still evolving. Someday, governments may issue decentralized, blockchain-based identities, eliminating the need for platform-specific identifiers like usernames.
Until then, developers and identity management vendors will continue to anticipate risks and monitor threats. We spoke with three identity management experts about the basics of building and operating these systems. Because now, more than ever, it’s critical to get it right.
“The flip side of identity ‘having a moment’ is that identity is having a moment,” Kiser said. “People are realizing the importance of it. And if it doesn’t work, you can’t say to people, ‘Well, we tried.’”
What is an identity management system?
GARY ALLISON
VP of engineering, Ping Identity
An identity management system [provided by a vendor] is designed to take care of all the complexities around managing and securing the identity of your users so that you don’t have to build it yourself.
ED SAWMA
Senior director of product marketing, Okta
There’s workforce identity, which is in the context of a company or an organization. They have to manage the identities of everybody involved in that organization — employees, contractors, partners — as well as how they access the different applications that that organization uses. And then there’s customer identity, which software developers have to deal with. Every application that has information about a user has to build identity into that app.
MIKE KISER
Senior security strategist, SailPoint
The easiest way to describe it is like a club where there’s a bouncer. And he checks your identity and allows you to enter — or doesn’t. Identity management basically provides that bouncer with a list of who’s in and who’s out. What that means is when someone joins your organization, you have resources and applications and data that person needs to access. From the minute they walk in the door, you should know enough about who they are and what they need to set them up with all those accounts and all of the right access to make them productive as quickly as possible, but also prevent them from accessing something they shouldn’t.
What are the requirements of an excellent identity management system?
SAWMA: An excellent identity management system shouldn’t have a stake in the ground in terms of what development environment it prefers. Like, you don’t want something that’s only going to work in Amazon Web Services or Microsoft’s cloud. And it has to be available around the clock. A good identity platform should basically never go down.
ALLISON: What’s very important is the mobile use case and having a strong multi-factor authentication story, whether that’s through a mobile device or through hardware tokens or through integration with other software tokens like Google Authenticator. Multi-factor authentication through a secondary means is really essential.
Then, consider the standards it offers. You’re going to want a strong [Security Assertion Markup Language] capability. You’re gonna want strong OpenID Connect capability. You’re going to want strong social log-in capability. And then you want to be able to map any of these protocols to any other of the protocols to federate the sign-in across many websites.
KISER: It should provide some documentation for auditors. Because auditors are going to come in and ask, “Are you securing your data and your applications and your resources?”
It should also be really easy to use and thoughtfully designed. You want people using it, instead of going their own way and doing things outside the system. That’s often an underrated thing. Think about face ID on your phone, for instance. That got adopted because it was easy. The more technology gets out of the way and accelerates people instead of slowing them down, the better it is.
What are some best practices for building an identity management system?
ALLISON: Build on a microservice-based architecture, and make that microservice-based architecture available in multiple regions. We have multiple geographic cloud regions serving authentication requests.
When you’re building a house, the plumber has to come in and lay the plumbing before the foundation people can come pour the concrete, right? And every team building the house is dependent on other teams finishing their parts first. That’s the worst thing you can do when building software. It’s very complex and slow. But when the core of your architecture is a microservices-based architecture, you have smaller pieces that operate independently and pass messages back and forth. That means each team can build and deliver faster.
SAWMA: You want monitoring at every layer in your identity stacks. You want monitoring in terms of events, you want monitoring in terms of authentications, and then you want redundancy for those monitoring systems. If you’ve got a problem in your identity stack, you want to know right away.
You also want to incorporate different protocols and technologies for connectivity, whether it’s legacy Federation protocols like SAML or more modern ones like OpenID Connect. For example, WebAuthn is the newest authenticator type out there. The browser in your MacBook is now prebuilt to use Web Authn. Windows Hello is Web Authn compatible as well. You want to support all kinds of different authenticators.
KISER: The worst case scenario [when building an identity management system for a customer] is you throw something in and it doesn’t quite work. And by the time they realize it, you’re gone. No matter your technology, you need to plan to partner with your customers. And that means being up front about what you can and can’t do, from a technology perspective.
What are the biggest challenges identity management systems pose for developers and enterprises?
SAWMA: I think for developers, it starts small and they think it’s something simple. If you’re building an app, for example, there’s usually an open source library you can plug in that’s going to handle authentication. And you can store the app’s usernames and passwords in a database and then encrypt that.
But it starts to get complicated as soon as an application achieves some amount of scale. You start thinking about how to add security, how to monitor access and make sure that information is available 24/7. And then you get into additional identity use cases. You want to add social log-in, and there might be some B2B customers who want to access the app with their own employee identities. So that’s another layer of things you have to build, and it all starts to snowball.
KISER: Alongside connectivity and visibility, you have to think about efficiencies of scale. Because you’re giving people access, and then on the back end you’re trying to check that access. And that can quickly scale beyond normal realms. So, on the enterprise side, if you’re managing five people and you need to evaluate all of their access, that can be cumbersome, especially if you have to do it on a regular basis. To that end, we’re seeing a wave of adoption of machine learning to identify where things are normal and where things are not.
In other words, if we see an employee in accounting suddenly accessing engineering codes from someplace in Botswana, we’re going to say that’s unusual. And we can use machine learning concepts to learn what’s normal and what’s not, and then start to enforce that and take some burden off human operators.
ALLISON: You have to balance keeping up with industry standards and keeping up with demands from your users for ease of use, because the standards are evolving all the time. One of the latest standards we’re very excited about is called Fast Identity Online, or FIDO. The power of FIDO is that it’s a more secure way of authenticating that can eliminate the need for passwords. But, if you were a developer, that would be yet another set of standards to learn and integrate.
What common missteps do you see as people build or implement identity management systems?
KISER: For enterprises, it’s trying to do too much too quickly. There’s something called a “role” within identity governance that helps group users with other people like them. In the past, we’ve seen organizations make more roles than the actual number of users they have. So, instead of getting efficiency of scale, they actually weaken their approach.
Another misstep is viewing identity governance as a project. It’s not a one-and-done kind of thing. It should be an ongoing program where you rethink, evaluate and renew your actions.
SAWMA: For developers, there are definitely some “gotchas.” Take the Olaf standard, which is how you give an application a “token” to get secure access to a user’s identity. A lot of developers don’t build token revocation into their apps. When they suddenly decide an app is no longer secure and they don’t want to allow the app to access a user’s data, there’s a problem, because they’ve given it a token, and it can keep accessing things. If you don’t have a way to revoke that token and remove that access, you’ve opened up a big security hole.
ALLISON: You have to make sure personal data isn’t just encrypted in the database, but that it’s encrypted as it’s passed from service to service inside your application. That way, if an attacker breaches the outer protection of your network and gets within your network, they’re not able to see these messages passed around between the services. A lot of people forget about that.
Also, if you host your system with one of the cloud providers, you need to make sure it’s seamlessly available in more than one region. Because this is a single point of failure. If users can’t authenticate — or, once they’ve authenticated, they can’t re-authenticate — then your application is effectively down.
What are the biggest shifts you’re seeing in the identity space right now?
KISER: With the explosion of cloud, enterprises are facing new realities. In the old days, you could expect your resources to be on premise and located in one facility protected by a single network. And that’s no longer true. If you’ve seen the marketing hype recently about something called “zero trust,” that’s a reflection of this. Zero trust just means you can’t trust someone because of what network they’re on what building they’re in. So it’s a more in-depth defense concept that relies on identity. If you’re trying to decide whether to give someone access to something, the system that sets up that access has to know who the person is.
ALLISON: We’re moving toward a passwordless future. Passwords are inherently vulnerable. There are all kinds of social engineering attacks to get passwords that people fall prey to, unfortunately. But there are new standards that are moving very quickly where identity is decentralized and can be built into things like your phone. So the proximity of your phone to your computer would provide the authentication and eliminate any need for a password.
SAWMA: Privacy regulations. They’re very powerful, and I think it’s a fantastic evolution for us as an industry to give more power to the user. But the requirements they place on developers are pretty onerous. And it’s not just that there are a lot of requirements — sometimes they can be vague. So I don’t think there are any black or white answers, and if there’s a vendor out there saying they have this all buttoned up and solved, it’s probably not true. I think it’s a journey.