By Prabath Siriwardena
Director - Security Architecture, WSO2
Today, the global Internet economy is estimated to be around of $10 trillion US dollars; in the next couple of years, almost half the world’s population (about 3 billion people) is set to get their hands on the Internet. And it doesn’t just end there - in 2008, the number of things connected to the Internet exceeded the number of people on earth. To put this into perspective, over 12.5 billion devices were connected to the Internet in 2012. It is estimated that at least 50 billion devices will be connected to the Internet by end-2020.
Connected devices have existed in one form or another since the introduction of the first computer network and consumer electronics. However, global connectivity started to take shape only after the Internet emerged. In the 1990s the possible communication between people and machines and interaction via machines was only a concept; today it’s a reality that’s continuing to evolve.
The concept of ‘identity’ is not confined to just humans anymore, but rather represents both humans and ‘things’. The identity of things (IDoT) is an effort that involves assigning unique identifiers (UID) with associated metadata to devices and objects (things), enabling them to connect and communicate effectively with other entities over the Internet.
The metadata associated with the unique identifier collectively defines the identity of an endpoint. IDoT is an essential component of the Internet of things (IoT), in which almost anything imaginable can be addressed and networked for exchange of data online. In this context, a thing can be any entity, both physical and logical objects, that has a unique identifier and has the ability to transfer data over a network.
The definition of identity has evolved with IoT and cannot be defined by just attributes or claims. It can be further refined by patterns or behaviors. Yet, the complete picture of a given entity’s identity is unavailable. Moreover, the privacy of data migration and ownership is another challenge we face in today’s connected world. For example, the connected car is among the millions of Internet-connected devices available today - it can collect and store a vast amount of data that can go well beyond the vehicle owner’s personal preferences and settings; the car can collect driver data such as travel routes, travel destinations, car speeds, driver behavior, and commute patterns among many other nuggets of information.
All of the data collected and stored by these IoT devices are helping to create a “virtual identity” for each and every user. While this user-generated data will most likely last forever, connected cars and all the other Internet-connected devices will eventually phase out. In the context of the connected car, it would lead to important questions concerning car owners and their data, such as how and where this data is stored, the fate of the already collected data when the owner buys a new car, and the possibility of transferring this data to another connected car even if the car is built by a different manufacturer. Connected car data and user preferences are primarily stored in cloud-based silos.
There are no universal standards or best practices among car manufacturers or industry players for collecting, storing, and managing data of connected car owners. Moreover, there are no universal standards or best practices to manage the ‘identity’ of connected car owners, which includes the storage and export of personal preferences and user history.
Identity silos create a lot of friction in the connected business. One way to reduce friction, while keeping data in silos as well as the ownership of data is to expose identity data via APIs to help users establish a clear identity. By doing this, they would be able to, for instance, relate driving patterns with sleeping patterns or daily food consumption patterns with sleeping patterns, etc. The impending challenge, however, is propagating end-user identity across these APIs; therefore, building a protocol agnostic security model is key to ensure connected identity. The security model of one entity should be compatible with other connected devices. This would amount to building a point-to-point security model that would lead to the spaghetti identity anti-pattern.
Identity silos and spaghetti identity anti-patterns are not only present in the IoT world. Even in the past, most enterprises have expanded via acquisitions, mergers, and partnerships, thereby including more external users into their system. An analyst firm has even predicted that by 2020 around 60% of all digital identities interacting with enterprises will come from external identity providers.
Each external identity provider can be treated as an identity silo and identity data is shared via APIs. The identity consumer, or service provider, must trust the identity provider to accept a given user identity. Beyond the trust, both the service provider and identity provider must speak the same language to establish trust and then transport identity data. In the case of a service provider that doesn’t comply with the identity token sharing protocol supported by the identity provider, you would either need to fix the identity provider’s end to speak the same language of the service provider, or vice versa.
The connected business space today involves a very dynamic environment. An enterprise’s goal is to reach out to as many customers, partners, distributors, and suppliers that would result in more business interactions and subsequently translate to revenue growth. Their ultimate goal, however, should be to make the business more accessible and reactive rather than just simply integrating technological silos. Ensuring there’s no friction in building connections between business entities comes at a price and with certain limitations - the cost of provisioning a service provider or an identity provider into the system could be high due to protocol incompatibilities. In addition, building point-to-point trust relationships between service providers and identity providers is not scalable.
With the identity bus or the identity broker pattern, a given service provider is not coupled to a specific identity provider as well as to a given federation protocol. The broker maintains the trust relationships between each entity as well as identity tokens between multiple heterogeneous security protocols. It can further enforce access controlling, auditing, and monitoring. Given the ongoing evolution in standards for identity federation and the lack of proper standards to manage and propagate device identities, the identity broker will play a key role in building a common, connected identity platform in a protocol agnostic manner.
The identity broker pattern has the following key benefits:
The following fundamentals should ideally be supported by an identity broker to be able to meet future identity and access management requirements:
Figure 01
Figure 02
Figure 03
Figure 04
Figure 05
Figure 06
Figure 07
Figure 08
Figure 09
Figure 10
Figure 11
Figure 12
Figure 13
Figure 14
Figure 15
WSO2 Identity Server provides a comprehensive security model based on OAuth 2.0 to secure access to APIs. Further, the XACML 3.0 support in WSO2 Identity Server can be leveraged to build a fine-grained access control model. WSO2 Identity Server along with WSO2 API Manager can build a comprehensive API security ecosystem for an enterprise.
Connected devices is not a concept anymore. In fact, it’s evolving at a dynamic pace. Enterprises too need to adapt and find ways to manage the challenges that follow too. Ultimately, an enterprise’s goal is to increase and expand business interactions with the parties it deals with and eventually translate these to revenue growth. The real challenge, however, is to find ways to make their businesses more accessible and reactive rather than just simply integrating technological silos. When doing so, security and identity management plays a critical role in efforts to enhance end-user experience.
WSO2 efficiently undertakes the complex task of identity management across enterprise applications, services, and APIs by utilizing the full breadth of the WSO2 platform. The WSO2 open source model avoids vendor lock-in and enables integration across systems, acting as a fully functional enterprise identity bus.
For more details about our solutions or to discuss a specific requirement