The State of Digital Identity in 2016

A journalist recently reached out to Gluu with some questions about how the Identity Management industry is evolving to keep up with modern technological advancements. I thought the LinkedIn community could also benefit from my answers. 

Enjoy!

What are the latest advances in Identity Management technology?

Identity management (or "IDM") is how an organization manages changing user information. For example, when an organization hires an employee, or a consumer enrolls at a website, a record is created. When a person changes their password (or some other credential), they update their record. A person may be fired from an organization, or want their account removed from a website. Or perhaps you need to change your name, or you are assigned a new role within an organization. All of the above examples require "IDM Workflows"--a fancy way to say that data needs to change--either be added, updated or deleted.

IDM is primarily a business process issue, not a technology issue. So the truth is, there have been minimal advances in IDM in the last decade. How we move data in and out of a database is pretty much the same. We may use JSON instead of XML, or some other database technology instead of SQL, but these format changes are not a big deal.

How has IDM evolved over the years?

In the IDM market sector, we have had large enterprise software vendors that provide productive toolkits for managing identity since around the year 2000. Many organizations (or let's say Internet "domains"), have home-grown tools for IDM. When you register on a website, it creates a user record in the database--that's a simple IDM workflow.

Over the years, one interesting change has been that IDM tools have bifurcated. There is a new category of tools called Identity Access Governance, which provides some reporting, and compliance features. Originally these features were part of the IDM tools, but the requirements became complex enough to necessitate the creation of a separate category of tools.

There are also some new protocols for Identity Management. Of course there is SCIM, the System for Cross-domain Identity Management, which is now complete and published under the IETF. It includes a JSON / REST API that defines a standard /Users endpoint. You can POST to the /Users API to add a user, PUT to edit a user, DELETE to remove a user, and so on. SCIM is not really revolutionary... its just an alignment of existing industry best practices. For example, do Google and Salesforce really need a different /Users endpoint? Of course not...

But SCIM doesn't really change the underlying challenge of IDM. It doesn't make it much easier. You still need to know what to do when user information changes.

What happens to privacy when biometrics are thrown into the mix?

It's risky for people to store biometric information on websites, because you can change your password, but you can't change your biometrics.

There is no question that biometrics will be an important strategy for person identification for a number of domains. In the past, we've relied on cognitive strategies (something you know, like a password) to bridge the digital-analog world.

Digital identification is never perfect. There is a trade off between usability, security, and deployability. Each website needs to weigh these factors, and deploy a strategy that mitigates sufficient risk for the transactions they want to enable.

To date, there is no silver bullet for biometric authentication. If there were, the FBI wouldn't have just created a 1,000 person biometrics center to study the challenge. If the problem is ever solved, there will probably be no "eureka" silver bullet. It will be a mix of client software, new algorithms, new sensors and new contextual analysis techniques.

How are ID management systems and access management/roles-based management converging?

A person's role in an organization is just one way to determine what access they should be granted. Since the inception of access management, roles have always been a handy way to make policies about who can get to what resources. But it's never been the only consideration--what website you are using to make your request, what contextual information is available (for example, is the request coming from a foreign country, time of day), calls to external systems for fraud detection and a number of other factors may be included to make a policy access decision.

Maybe the one change is that standards for centralized policy management have emerged over the years. The first central policy servers were commercial--like Computer Associates SiteMinder, IBM Tivoli Access Manager, and Oracle Access Manager. Over time, open standards have emerged, and even open source software to address this organizational requirement. OAuth2 is particularly well suited to implement centralized policy management. We've already seen OAuth2 profiles emerge like the User Managed Access Protocol ("UMA") and OpenID Connect, which enable an organization to control access to a resource (API).

ID management has been largely about people in the past. How will the Internet of Things change that, if at all?

IOT offers some new possibilities for user identification--a person's proximity to certain IOT devices mitigates a certain amount of fraud risk. For example, if I'm in my car, wearing my IOT watch, glasses and fitness tracker--that's interesting data to support that it's really me.

IOT is also pushing the boundaries for OAuth2. One of the current assumptions of OAuth2 is that it uses TCP/IP as the network protocol (HTTP is a tcp protocol) and TLS (Transport Layer Security--encrypted traffic between the client and server). However, IOT devices may not have enough memory or CPU to use this network stack. So new parallel profiles of OAuth2 may need to be written to support UDP (instead of TCP) and DTLS (instead of TLS). With UDP, packets are sent, but not re-sent if they are lost. In the past, technology changes like this have pulled the rug out from under standards efforts. Will OAuth2 be able to adapt?

IOT will also test the boundaries of a person's ability to authorize devices to act on his behalf. To be productive, we want to NOT do something... we want to delegate some tasks to our devices. If I have to manage each device as a one-off, the number of devices I can manage will be limited.

So it's possible that while in the past centralized policy management was something that was performed only by large organizations, IOT may create the requirement for personal policy management. We'll need more ways to point our devices at a central control point, which will give us the ability to manage (i.e. change and revoke) security policies. Unless you want to buy a household of devices all by the same vendor (Apple would love that...), we'll need standards for both security, and trust management.

Is authentication keeping up with trends in ID management?

There is certainly no lack of authentication technologies (just check the slides from my recent RSA Conference presentation!). So why are most domains still using passwords? According to Microsoft, the main impediment is deployability. Passwords are free. And they are easy to implement. And if you are an organization, and you have a bunch of websites, upgrading each website to two-factor authentication is an expensive proposition. So is managing stronger credentials--password reset is hard enough, what about when you lose your token, or your biometric is compromised?

One of the reasons we may be in a better place to solve the deployability problem is because of open standards for the API's that applications use to identify people (like OpenID Connect and UMA). This means that instead of each application doing a one-off two-factor authentication integration, many applications can utilize a central server which authenticates the person.

My identity as my wife sees it may be different to my identity as my bank sees it, which may be different again to my identity as my employer sees it. How do we cope with multiple attributes in ID management?

Your identity is always in the context of a domain. This will continue to be true forever. Your bank, your telephone company, your worksite, your consumer IDP (google, facebook), will never stop issuing you credentials--because it's in their critical business interest. To the extent that you want to connect your identities in these various domains should be up to you.

Also, better collaboration between domains is needed. Right now, its very hard for one domain to know if it can trust another domain. In a multi-party federation (like InCommon in the university space), each participant signs a "Participant Agreement"--and agrees to protect identity data. Currently, its too hard to form federations, so most domains use one-to-one agreements. This does not scale well, especially in complex ecosystems like government and healthcare. We need more federations, which is one of the reasons I helped start the Open Trust Taxonomy for OAuth2 (OTTO) workgroup at Kantara.

How do we maintain and preserve identity in the long term, as a person's life and circumstances change?

As the Internet is decentralized, and each domain is in charge of its own data about people, that's up to the domain in question. Would more centralization be better? Not necessarily. Centralization creates a big target.

Are there standards for ID management?

From a legal perspective, the laws for identity management are not standardized at all. You'll find various legal requirements that may affect the type of protection a firm must use to protect data, how much control a person has to change data, and how much assurance a domain offers when accessing services on a person's behalf.

From a technical perspective, we have some standards for centralized authentication and authorization. But tools without rules are not as helpful as they may seem.

What are the biggest challenges facing companies that want to design and deploy their own ID management systems?

The biggest challenge I see is that there aren't enough people out there who understand identity technology. When I talk to companies, they might get issues from the silos in the above diagram mixed up. If IT architects don't even understand the different parts that make up an identity solution, how are they going to architect a solution?

The other issue contributing to the resource problem is that identity management has been kept a secret. It's hard to find books about the topic. Much of the know-how is trade secret, maintained by integration firms, vendors and industry analysts.

And finally, the system is stacked against open source identity software providers which are needed to get identity into the hands of the numerous domains with which a person does business. At Gluu, maintaining our commitment to free open source software has involved big sacrifices. The best way to describe it is in the economic terms of a tragedy of the commons. Everyone wants the software, but no one wants to pay. So you can't blame commercial vendors for charging large sums for their software. But at the same time, this high price creates scarcity which does not benefit anyone--particularly consumers. The government will waste $38M to build tools to break 2016 encryption, but how much gets spent to fund open source projects that would benefit millions of businesses and consumers?

Should you have questions about this topic, please schedule a meeting with me to discuss further.

If you need to identity customers, partners, employees, and devices, you should check out the free open source Gluu Server.  Using a Gluu Server, you can centralize your organization's authentication and authorization service and leverage open web standards to enable federated single sign-on (SSO), strong multi-factor authentication, and web and API access management.

More posts from Mike Schwartz:

• Authorization (authZ) is the new Authentication (authN)
• 10 tips for your next Identity and Access Management (IAM) project
• 5 Reasons You Need OpenID Connect and UMA in Your Identity and Access Management (IAM) Stack
• Ideas on managing IoT in your house

Like this post? Great! Follow Gluu on Twitter @gluufederation. It would be great if you shared this post too. Thanks!