Gervas Douglas
2012-12-16 15:22:25 UTC
Turning Identity-as-a-Service Inside Out
Document ID: | Document Type: ZapFlash
By: /Jason Bloomberg/ | Posted: /November 28, 2012/
Simple question with a surprisingly complex answer: who owns your
identity? Our first instinct is to insist that we each own our own
identities. After all, we /are/ our identities, right?
Not so fast. There are myriad players who own a piece of your identity,
from the credit bureaus to your bank to Facebook to your doctor to your
employer. Every single one has some kind of identity management system
that keeps track of information about you. In fact, this personally
identifiable information (PII) is so powerful that when someone steals
it, we call that crime /identity theft/ -- as though stealing your PII
was the equivalent of stealing your very soul.
The reason PII has such power, of course, is because we give it power.
Knowing a username and password gives you the power to access a system.
Knowing your Social Security Number and birth date may give you the
power to get bank account information from a call center rep. Add a bit
more knowledge and you have the power to apply for a loan or a job or a
security clearance. The old adage states that /knowledge is power/, but
information only has power if we choose to empower it.
From the perspective of IT, managing user identities has long been in
our wheelhouse. The Identity and Access Management (IAM) market matured
years ago, and all enterprises have a broad set of robust IAM
alternatives to choose from. But hey, it's almost 2013, right? Why buy
some IAM product I have to install and maintain. Why don't I just get it
in the Cloud?
*The Problem with Identity-as-a-Service*
No brainer, right? Sign up for Identity-as-a-Service (IDaaS), or perhaps
call it Identity Management as a Service (IDMaaS) or IAM as a Service
(IAMaaS) -- the marketplace still hasn't settled on the term -- and you
can throw away your Active Directory or LDAP. If all your users want to
do is access the Software-as-a-Service (SaaS) offerings you provide,
then placing your user directory in the Cloud is an obvious choice. Even
when you want to control access to on-premise applications, IDaaS might
make sense. After all, your current IAM solution connects to the apps in
question over the network as it is. What does it matter whether IAM is
running in the Cloud or not? Just put your user directory in the Cloud,
configure it to control access to all your apps, and call it a day.
The problem is, this "put all the users in a directory" approach to IAM
is increasingly inadequate to cover the kinds of identity management
scenarios that we're facing in our maddeningly complex, interconnected
world. But this story isn't new, either; after all, federated identity
standards and technologies have been around for a decade or more. With
federated identity, two separate security domains (that is, different
departments or organizations with their own IAM systems) can exchange
identity information with each other securely. Think of one of the
travel aggregators, like Orbitz or Travelocity. Log into the aggregator
Web site and you can purchase tickets and hotel rooms and the like,
without ever contacting the airline or hotel directly. Behind the scenes
the aggregator and the service provider are exchanging secure tokens
that contain a bit of your identity, along with the appropriate
instructions.
Federated identity is an essential enabler of Cloud security as well,
particularly when the enterprise isn't comfortable moving their IAM to
the Cloud. In fact, federating on-premise identity to the Cloud is a
central technique we discuss in our Cloud Computing for Architects
<http://t.ymlp239.net/eujbuaxahhebakauumaoambmuu/click.php> course. But
it's not the same as IDaaS, where an organization actually moves its
user directory to the Cloud. And federated identity breaks down when
there are too many participants in a complex interaction, like the types
of interactions that are becoming increasingly common in the Cloud.
So far so good: IDaaS isn't right for every organization today, but it
could easily belong somewhere on your Cloud roadmap. But even when you
reach a level of maturity where you're comfortable moving your IAM to
the Cloud, IDaaS still falls short, because it doesn't take into account
how we as individuals would like to think about our identities. From the
perspective of the user, IDaaS moves the control over our own identities
even further away from the user -- and that's not the way we consumers
view the Cloud. From the perspective of the user, the Cloud should
empower us. IDaaS does the opposite.
*Identity as a Cloud Resource*
The reason so many vendors fell into this trap with IDaaS is essentially
the horseless carriage problem: we have IAM, we want to move to the
Cloud, so let's put IAM in the Cloud -- instead of rethinking the
problem from the perspective of what the Cloud actually means. So, let's
think about this problem in an entirely different way. Instead of
beginning with the user directory at the heart of every IAM offering,
let's begin with the user identity itself.
Essentially, we'd like to have some kind of /avatar/: a digital
representation of our identity that the user controls for themselves. In
other words, something like a digital wallet or key ring that manages
PII on behalf of the user. Such technologies have been around for a few
decades, of course; in fact, the whole idea of a digital wallet dates
from the dot.com era in the 1990s. But such technologies didn't take
off, for two reasons. First, big companies didn't like the idea of
giving their customers control of their own identities. Second, we
didn't have the Cloud.
Let's put off the discussion of control for a moment, because putting
the Cloud piece into the puzzle will help us deal with the control
issue. We need to consider the Cloud, however, because it changes
everything. What the Cloud brings to the table is not just the ability
to treat identity management as a /service/. It also enables us to treat
identities themselves as /Cloud resources/.
As we discussed in an earlier ZapFlash
<http://t.ymlp239.net/eujbealahhebapauumacambmuu/click.php>, there are
many different types of Cloud resources, including servers, storage,
networks, queues, etc. Furthermore, the list isn't fixed. As Cloud
Computing matures, we expect and encourage new types of resources. What
makes them /Cloud/ resources is that the /user/ is able to dynamically
provision and deprovision them with minimal management effort or service
provider interaction.
So, let's take the notion of a user identity -- or to be more precise,
the user's avatar -- and consider it to be a Cloud resource. The user,
that is, /we/ can provision such avatars as we see fit. And because
they're in the Cloud, they're location independent. Facebook could /use/
our avatar. Assign it privileges or other properties. Or our bank. Or
our employer. But /we/ control it.
Furthermore, we can choose /how/ we control our Avatar. We may wish to
log into its Web interface, but that's only one option. We could also
use a hardware device like a flash drive or a USB dongle. We could add
biometrics to the device, say via a fingerprint reader. Or we could
install software on our computers that would enable us to control the
avatar.
Treating identities as Cloud resources can also provide privacy
boundaries. For example, I might instruct my avatar to provide my Social
Security Number to my bank and the IRS, but not to Facebook. And of
course, one of the primary benefits of this approach is that I can
maintain my personal information in a single place. If I move, I notify
my avatar, and everyone I've authorized to see my address automatically
gets the update.
*The ZapThink Take*
In fact, treating identity as a provisionable Cloud resource -- an
avatar in the Cloud -- makes so much sense that you might wonder why
nobody has already made a billion dollars on this idea. The answer, of
course, is /control/. Remember all the hullabaloo when Microsoft tried
to position Passport as a general purpose identity store
<http://t.ymlp239.net/eujbmadahhebaiauumazambmuu/click.php>? Customers
rebelled and Microsoft ended up in court -- several times, in fact.
Fundamentally, nobody wanted Microsoft to be in control of our identities.
Today we're going through a similar situation with Facebook, Twitter,
and the like. Why bother creating yet another login with yet another
password to forget, when we can simply log into that new site with our
Facebook ID? Yes, we all go along, until we eventually realize we really
don't want to give Facebook so much control over our online identity.
The Cloud, at least in theory, shifts this control to the user. The
/user/ should be responsible for provisioning Cloud resources. Yes,
there needs to be software behind the scenes that makes provisionable
avatars work and keeps them secure, but if they are truly Cloud
resources, the Cloud service providers won't control them. Their
customers will.
Document ID: | Document Type: ZapFlash
By: /Jason Bloomberg/ | Posted: /November 28, 2012/
Simple question with a surprisingly complex answer: who owns your
identity? Our first instinct is to insist that we each own our own
identities. After all, we /are/ our identities, right?
Not so fast. There are myriad players who own a piece of your identity,
from the credit bureaus to your bank to Facebook to your doctor to your
employer. Every single one has some kind of identity management system
that keeps track of information about you. In fact, this personally
identifiable information (PII) is so powerful that when someone steals
it, we call that crime /identity theft/ -- as though stealing your PII
was the equivalent of stealing your very soul.
The reason PII has such power, of course, is because we give it power.
Knowing a username and password gives you the power to access a system.
Knowing your Social Security Number and birth date may give you the
power to get bank account information from a call center rep. Add a bit
more knowledge and you have the power to apply for a loan or a job or a
security clearance. The old adage states that /knowledge is power/, but
information only has power if we choose to empower it.
From the perspective of IT, managing user identities has long been in
our wheelhouse. The Identity and Access Management (IAM) market matured
years ago, and all enterprises have a broad set of robust IAM
alternatives to choose from. But hey, it's almost 2013, right? Why buy
some IAM product I have to install and maintain. Why don't I just get it
in the Cloud?
*The Problem with Identity-as-a-Service*
No brainer, right? Sign up for Identity-as-a-Service (IDaaS), or perhaps
call it Identity Management as a Service (IDMaaS) or IAM as a Service
(IAMaaS) -- the marketplace still hasn't settled on the term -- and you
can throw away your Active Directory or LDAP. If all your users want to
do is access the Software-as-a-Service (SaaS) offerings you provide,
then placing your user directory in the Cloud is an obvious choice. Even
when you want to control access to on-premise applications, IDaaS might
make sense. After all, your current IAM solution connects to the apps in
question over the network as it is. What does it matter whether IAM is
running in the Cloud or not? Just put your user directory in the Cloud,
configure it to control access to all your apps, and call it a day.
The problem is, this "put all the users in a directory" approach to IAM
is increasingly inadequate to cover the kinds of identity management
scenarios that we're facing in our maddeningly complex, interconnected
world. But this story isn't new, either; after all, federated identity
standards and technologies have been around for a decade or more. With
federated identity, two separate security domains (that is, different
departments or organizations with their own IAM systems) can exchange
identity information with each other securely. Think of one of the
travel aggregators, like Orbitz or Travelocity. Log into the aggregator
Web site and you can purchase tickets and hotel rooms and the like,
without ever contacting the airline or hotel directly. Behind the scenes
the aggregator and the service provider are exchanging secure tokens
that contain a bit of your identity, along with the appropriate
instructions.
Federated identity is an essential enabler of Cloud security as well,
particularly when the enterprise isn't comfortable moving their IAM to
the Cloud. In fact, federating on-premise identity to the Cloud is a
central technique we discuss in our Cloud Computing for Architects
<http://t.ymlp239.net/eujbuaxahhebakauumaoambmuu/click.php> course. But
it's not the same as IDaaS, where an organization actually moves its
user directory to the Cloud. And federated identity breaks down when
there are too many participants in a complex interaction, like the types
of interactions that are becoming increasingly common in the Cloud.
So far so good: IDaaS isn't right for every organization today, but it
could easily belong somewhere on your Cloud roadmap. But even when you
reach a level of maturity where you're comfortable moving your IAM to
the Cloud, IDaaS still falls short, because it doesn't take into account
how we as individuals would like to think about our identities. From the
perspective of the user, IDaaS moves the control over our own identities
even further away from the user -- and that's not the way we consumers
view the Cloud. From the perspective of the user, the Cloud should
empower us. IDaaS does the opposite.
*Identity as a Cloud Resource*
The reason so many vendors fell into this trap with IDaaS is essentially
the horseless carriage problem: we have IAM, we want to move to the
Cloud, so let's put IAM in the Cloud -- instead of rethinking the
problem from the perspective of what the Cloud actually means. So, let's
think about this problem in an entirely different way. Instead of
beginning with the user directory at the heart of every IAM offering,
let's begin with the user identity itself.
Essentially, we'd like to have some kind of /avatar/: a digital
representation of our identity that the user controls for themselves. In
other words, something like a digital wallet or key ring that manages
PII on behalf of the user. Such technologies have been around for a few
decades, of course; in fact, the whole idea of a digital wallet dates
from the dot.com era in the 1990s. But such technologies didn't take
off, for two reasons. First, big companies didn't like the idea of
giving their customers control of their own identities. Second, we
didn't have the Cloud.
Let's put off the discussion of control for a moment, because putting
the Cloud piece into the puzzle will help us deal with the control
issue. We need to consider the Cloud, however, because it changes
everything. What the Cloud brings to the table is not just the ability
to treat identity management as a /service/. It also enables us to treat
identities themselves as /Cloud resources/.
As we discussed in an earlier ZapFlash
<http://t.ymlp239.net/eujbealahhebapauumacambmuu/click.php>, there are
many different types of Cloud resources, including servers, storage,
networks, queues, etc. Furthermore, the list isn't fixed. As Cloud
Computing matures, we expect and encourage new types of resources. What
makes them /Cloud/ resources is that the /user/ is able to dynamically
provision and deprovision them with minimal management effort or service
provider interaction.
So, let's take the notion of a user identity -- or to be more precise,
the user's avatar -- and consider it to be a Cloud resource. The user,
that is, /we/ can provision such avatars as we see fit. And because
they're in the Cloud, they're location independent. Facebook could /use/
our avatar. Assign it privileges or other properties. Or our bank. Or
our employer. But /we/ control it.
Furthermore, we can choose /how/ we control our Avatar. We may wish to
log into its Web interface, but that's only one option. We could also
use a hardware device like a flash drive or a USB dongle. We could add
biometrics to the device, say via a fingerprint reader. Or we could
install software on our computers that would enable us to control the
avatar.
Treating identities as Cloud resources can also provide privacy
boundaries. For example, I might instruct my avatar to provide my Social
Security Number to my bank and the IRS, but not to Facebook. And of
course, one of the primary benefits of this approach is that I can
maintain my personal information in a single place. If I move, I notify
my avatar, and everyone I've authorized to see my address automatically
gets the update.
*The ZapThink Take*
In fact, treating identity as a provisionable Cloud resource -- an
avatar in the Cloud -- makes so much sense that you might wonder why
nobody has already made a billion dollars on this idea. The answer, of
course, is /control/. Remember all the hullabaloo when Microsoft tried
to position Passport as a general purpose identity store
<http://t.ymlp239.net/eujbmadahhebaiauumazambmuu/click.php>? Customers
rebelled and Microsoft ended up in court -- several times, in fact.
Fundamentally, nobody wanted Microsoft to be in control of our identities.
Today we're going through a similar situation with Facebook, Twitter,
and the like. Why bother creating yet another login with yet another
password to forget, when we can simply log into that new site with our
Facebook ID? Yes, we all go along, until we eventually realize we really
don't want to give Facebook so much control over our online identity.
The Cloud, at least in theory, shifts this control to the user. The
/user/ should be responsible for provisioning Cloud resources. Yes,
there needs to be software behind the scenes that makes provisionable
avatars work and keeps them secure, but if they are truly Cloud
resources, the Cloud service providers won't control them. Their
customers will.