It was a day in August 2012. Mat Honan - a reporter for the Wired magazine, San Francisco, returned home and was playing with his little daughter. He had no clue, what was going to happen next. Suddenly his iPhone was powered down. He was expecting a call - so he plugged it into a wall power socket and rebooted back. What he witnessed next blew him away. Instead of the iPhone home screen with all the apps - now it asks for him to set up a new phone with a big Apple logo and a welcome screen. Honan thought his iPhone was misbehaving - but was not that worried since he backed up daily to the iCloud - restoring everything from iCloud could simply fix this. Honan tried to login to iCloud. Tried once - failed. Tried again - failed. Again - failed. Thought he was excited. Tried once again… and failed. Now he knew something weird has happened. His last hope was his MacBook. Thought at least he could restore everything from the local backup. Booted up the MacBook - nothing in it - and prompted him to enter a four digit passcode - that he has never set up before.
Honan never gives up. He called Apple tech support to reclaim his iCloud account. Then he learnt he has called Apple, 30 minutes before, to reset his iCloud password. Only information required at that time to reset an iCloud account were, the billing address and the last four digits of the credit card. The billing address was readily available under the Whois internet domain record Honan had for his personal website. The attacker was good enough to get the last four digits of Honan’s credit card by talking to Amazon helpdesk - he already had Honan’s email address and the full mailing address - those were more than enough for a social engineering attack.
Honan lost almost everything. The attacker was still desperate - next he broke into Honan’s GMail account. Then from there to his Twitter account. One by one - Honan’s connected identity fall into the hands of the attacker.
Something we all know by heart - the principle of the weakest link. Any computer system is as strong as the strength of the weakest link in it. No matter you have biometrics to log in to your iPhone or to the MacBook - someone gaining access to your iCloud account can wipe off both of them.
Today, the global Internet economy is somewhere in the neighborhood of $10 trillion US dollars. By 2016, almost half the world’s population - about 3 billion people - will use the internet. Not just humans - during 2008 – the number of things connected to Internet exceeded the number of people on earth. Over 12.5 billion devices were connected to the Internet in 2012. It is estimated that 25 billion devices will be connected to the Internet by the end of 2015 - and by the end of 2020, 50 billion devices will be connected.
Connected devices have existed in one form or another since the introduction of the first computer networks and the consumer electronics. However, it wasn’t until the Internet emerged, that the idea of a globally connected planet started to take off. In 1990s researchers theorized how human and machine could weave together a completely new form of communication and interaction via machines. That reality is now unfolding before our eyes.
The word ‘Identity’ is no more just about humans. It 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. Identity of things 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 -- including both physical and logical objects -- that has a unique identifier and the ability to transfer data over a network.
The definition of Identity has evolved with the Internet of Things. Identity cannot be defined just by by attributes or claims. It can be further refined by patterns or behaviors. The Fitbit you wear while you sleep, knows your sleeping patterns. The sensors attached to your connected car knows your driving patterns. The sensors attached to your refrigerator knows your daily food consumption patterns. None of the identity stores out there can build a complete image of a given entity’s identity. Forget about the aggregated view - another challenge we face today in the connected world is the data migration and the ownership.
Connected cars collect and store a vast amount of data. This data goes well beyond a vehicle owner's personal preferences and settings. Connected cars collect driver data such as travel routes, travel destinations, car speeds, driver behavior, commute patterns and much more.
Connected cars are only a fraction of the millions and millions of Internet-connected devices that enable users to set their personal preferences and that collect vast amounts of user data. All of 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 not. This leads to several important questions concerning connected car owners and their data:
Identity silos create a lot of friction in the connected business. One way to reduce friction - but still keeping data in silos - and of course the ownership of data - is by exposing Identity data via APIs. That would help end users to build and understand a better picture of their own identity. Now they can relate driving patterns with sleeping patterns. The daily food consumption patterns with sleeping patterns and many more. The BMW Connected Drive, which connects to your Fitbit, now knows if you haven’t slept well last night - and possibly, present you the options that helps you for a safe drive.
Propagating end user identity across these APIs is the next challenge. Building a protocol agnostic security model is the key for connected identity. If we build BMW Connected Drive to be compliant with the security model of Fitbit, then, when it talks to Yelp to find the best nearby restaurant, that’s mostly rated by your friends in Facebook, BMW Connected Drive should then also be compatible with the security model of Facebook and Yelp. In other words, we are just starting to build a point to point security model, that would lead to the spaghetti identity - antipattern.
Identity silos and spaghetti identity anti-patterns are not only present in the IoT world.
If you look at the history, most enterprises grow today via acquisitions, mergers and partnerships. In U.S only, mergers and acquisitions volume totaled to $865.1 billion in the first nine months of 2013, according to Dealogic. That’s a 39% increase over the same period a year ago — and the highest nine-months total since 2008.
A research done by the analyst firm Quocirca confirms that many businesses now have more external users than internal ones: in Europe 58 percent transact directly with users from other businesses and/or consumers; for the UK alone the figure is 65 percent. Another analyst firm predicts by 2020, 60% of all digital identities interacting with enterprises will come from external IdPs.
Each external Identity Provider can be treated as an Identity silo. The way identity data are shared, is through APIs. The Identity consumer, or the service provider, must trust the identity provider to accept a given user identity. Beyond the trust, both the service provider - and the identity provider must speak the same language to bootstrap the trust relationship, and then transport identity data. How about a service provider, which is incompatible with the Identity token sharing protocol supported by the Identity provider? Either you need to fix the Identity provider end to speak the same language of the service provider, or the otherway around.
Under today’s context connected business is a very dynamic and complex environment. Your desire is to reach out to your customers, partners, distributors and suppliers and create more and more business interactions and activities, that will generate more revenue. The goal here is not just integrate technological silos, in your enterprise – but also make your business more accessible and reactive.
Having friction to build connections between your business entities - is something that cannot be tolerated. The cost of provisioning a service provider or an identity provider into the system could be high, due to the protocol incompatibilities. Also, building point-to-point trust relationships between service providers and identity providers - does not scale well.
With the Identity Bus or the Identity Broker pattern, a given service provider is not coupled to a given identity provider - and also not coupled to a given federation protocol. The broker maintains the trust relationships between each entity and also mediates identity tokens between multiple heterogeneous security protocols. It can further centrally enforce access controlling, auditing and monitoring.
With ever evolving standards for identity federation - and having no proper standard to manage and propagate device identities, Identity Broker will play a key role in building a common, connected identity platform in a protocol agnostic manner.
Following highlights some of the benefits of the Identity Broker pattern.
1. The Internet of Things (The MIT Press Essential Knowledge series), http://www.amazon.com/Internet-Things-Press-Essential-Knowledge/dp/0262527731
2. Future Crimes: Everything Is Connected, Everyone Is Vulnerable and What We Can Do About It, http://www.amazon.com/Future-Crimes-Everything-Connected-Vulnerable/dp/0385539002
3. http://www.programmableweb.com/news/identity-and-access-management-iam-will-greatly-impact-future-connected-car-sales/analysis/2014/08/20
Honan lost almost everything. The attacker was still desperate - next he broke into Honan’s GMail account. Then from there to his Twitter account. One by one - Honan’s connected identity fall into the hands of the attacker.
Something we all know by heart - the principle of the weakest link. Any computer system is as strong as the strength of the weakest link in it. No matter you have biometrics to log in to your iPhone or to the MacBook - someone gaining access to your iCloud account can wipe off both of them.
Today, the global Internet economy is somewhere in the neighborhood of $10 trillion US dollars. By 2016, almost half the world’s population - about 3 billion people - will use the internet. Not just humans - during 2008 – the number of things connected to Internet exceeded the number of people on earth. Over 12.5 billion devices were connected to the Internet in 2012. It is estimated that 25 billion devices will be connected to the Internet by the end of 2015 - and by the end of 2020, 50 billion devices will be connected.
Connected devices have existed in one form or another since the introduction of the first computer networks and the consumer electronics. However, it wasn’t until the Internet emerged, that the idea of a globally connected planet started to take off. In 1990s researchers theorized how human and machine could weave together a completely new form of communication and interaction via machines. That reality is now unfolding before our eyes.
The word ‘Identity’ is no more just about humans. It 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. Identity of things 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 -- including both physical and logical objects -- that has a unique identifier and the ability to transfer data over a network.
The definition of Identity has evolved with the Internet of Things. Identity cannot be defined just by by attributes or claims. It can be further refined by patterns or behaviors. The Fitbit you wear while you sleep, knows your sleeping patterns. The sensors attached to your connected car knows your driving patterns. The sensors attached to your refrigerator knows your daily food consumption patterns. None of the identity stores out there can build a complete image of a given entity’s identity. Forget about the aggregated view - another challenge we face today in the connected world is the data migration and the ownership.
Connected cars collect and store a vast amount of data. This data goes well beyond a vehicle owner's personal preferences and settings. Connected cars collect driver data such as travel routes, travel destinations, car speeds, driver behavior, commute patterns and much more.
Connected cars are only a fraction of the millions and millions of Internet-connected devices that enable users to set their personal preferences and that collect vast amounts of user data. All of 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 not. This leads to several important questions concerning connected car owners and their data:
- What happens to connected car owners' data when they want to purchase a new car?
- Can the car owner's data be transferred to another connected car, even if that car is made by a different manufacturer?
- How and where is all of these connected car data being stored?
Identity silos create a lot of friction in the connected business. One way to reduce friction - but still keeping data in silos - and of course the ownership of data - is by exposing Identity data via APIs. That would help end users to build and understand a better picture of their own identity. Now they can relate driving patterns with sleeping patterns. The daily food consumption patterns with sleeping patterns and many more. The BMW Connected Drive, which connects to your Fitbit, now knows if you haven’t slept well last night - and possibly, present you the options that helps you for a safe drive.
Propagating end user identity across these APIs is the next challenge. Building a protocol agnostic security model is the key for connected identity. If we build BMW Connected Drive to be compliant with the security model of Fitbit, then, when it talks to Yelp to find the best nearby restaurant, that’s mostly rated by your friends in Facebook, BMW Connected Drive should then also be compatible with the security model of Facebook and Yelp. In other words, we are just starting to build a point to point security model, that would lead to the spaghetti identity - antipattern.
Identity silos and spaghetti identity anti-patterns are not only present in the IoT world.
If you look at the history, most enterprises grow today via acquisitions, mergers and partnerships. In U.S only, mergers and acquisitions volume totaled to $865.1 billion in the first nine months of 2013, according to Dealogic. That’s a 39% increase over the same period a year ago — and the highest nine-months total since 2008.
A research done by the analyst firm Quocirca confirms that many businesses now have more external users than internal ones: in Europe 58 percent transact directly with users from other businesses and/or consumers; for the UK alone the figure is 65 percent. Another analyst firm predicts by 2020, 60% of all digital identities interacting with enterprises will come from external IdPs.
Each external Identity Provider can be treated as an Identity silo. The way identity data are shared, is through APIs. The Identity consumer, or the service provider, must trust the identity provider to accept a given user identity. Beyond the trust, both the service provider - and the identity provider must speak the same language to bootstrap the trust relationship, and then transport identity data. How about a service provider, which is incompatible with the Identity token sharing protocol supported by the Identity provider? Either you need to fix the Identity provider end to speak the same language of the service provider, or the otherway around.
Under today’s context connected business is a very dynamic and complex environment. Your desire is to reach out to your customers, partners, distributors and suppliers and create more and more business interactions and activities, that will generate more revenue. The goal here is not just integrate technological silos, in your enterprise – but also make your business more accessible and reactive.
Having friction to build connections between your business entities - is something that cannot be tolerated. The cost of provisioning a service provider or an identity provider into the system could be high, due to the protocol incompatibilities. Also, building point-to-point trust relationships between service providers and identity providers - does not scale well.
With the Identity Bus or the Identity Broker pattern, a given service provider is not coupled to a given identity provider - and also not coupled to a given federation protocol. The broker maintains the trust relationships between each entity and also mediates identity tokens between multiple heterogeneous security protocols. It can further centrally enforce access controlling, auditing and monitoring.
With ever evolving standards for identity federation - and having no proper standard to manage and propagate device identities, Identity Broker will play a key role in building a common, connected identity platform in a protocol agnostic manner.
Following highlights some of the benefits of the Identity Broker pattern.
- Introducing a new service provider is frictionless. You only need to register the service provider at the identity bus and from the there pick which identity providers it trusts. No need to add the service provider configuration to each and every identity provider.
- Removing an existing service provider is frictionless. You only need to remove the service provider from the identity bus. No need to remove the service provider from each and every identity provider. Introducing a new identity provider is frictionless. You only need to register the identity provider at the identity bus. It will be available for any service provider.
- Removing an existing identity provider is extremely easy. You only need to remove the identity provider from the identity bus.
- Enforcing new authentication protocols is frictionless. Say you need to authenticate users with both the username/password and duo-security (SMS based authentication) - you only need to add that capability to the identity bus and from there you pick the required set of authentication protocols against a given service provider at the time of service provider registration. Each service provider can pick how it wants to authenticate users at the identity bus.
- Claim transformations. Your service provider may read user's email address from the http://sp1.org/claims/email attribute id - but the identity provider of the user may send it as http://idp1.org/claims/emai. Identity bus can transform the claims it receives from the identity provider to the format expected by the service provider.
- Role mapping. Your service provider needs to authorize users once they are logged in. What the user can do at the identity provider is different from what the same user can do at the service provider. User's roles from the identity provider define what he can do at the identity provider. Service provider's roles define the things a user can do at the service provider. Identity bus is capable of mapping identity provider's roles to the service provider's roles. For example a user may bring idp-admin role from his identity provider - in a SAML response - then the identity bus will find the mapped service provider role corresponding to this, say sp-admin, and will add that into the SAML response returning back to the service provider from the identity bus.
- Just-in-time provisioning. Since identity bus is at the middle of all identity transactions - it can provision all external user identities to an internal user store. Centralized monitoring and auditing.
- Centralized access control.
- Introducing a new federation protocol needs minimal changes. If you have a service provider or an identity provider, which supports a proprietary federation protocol, then you only need to add that capability to the identity bus. No need to implement it at each and every identity provider or service provider.
1. The Internet of Things (The MIT Press Essential Knowledge series), http://www.amazon.com/Internet-Things-Press-Essential-Knowledge/dp/0262527731
2. Future Crimes: Everything Is Connected, Everyone Is Vulnerable and What We Can Do About It, http://www.amazon.com/Future-Crimes-Everything-Connected-Vulnerable/dp/0385539002
3. http://www.programmableweb.com/news/identity-and-access-management-iam-will-greatly-impact-future-connected-car-sales/analysis/2014/08/20