Defining Identity as a Service
In the midst of the holiday season, and with the anticipation and emotion that comes with the end of the year approaching, I have decided to write my first blog - an early new year's resolution perhaps. I must state that I have resisted the urge to blog for the last three years of my career for two reasons: on one end, I feared starting to blog and then dropping off and being inconsistent (just like I have been every time I started at the gym), on the other end, I dreaded becoming addicted to blogging and seeing it impact other priorities. But let's just say that I am resolved to give this a good try by sticking to some basic rules: keep the content lean but meaty, keep a constant blogging frequency, and try to be as interactive as feasible - sounds simple. Let's see how I fare (maybe I will also get in shape in the process)...
What is Identity as a Service (IDaaS)?
2009 has seen an increased interest and focus in a relatively new topic in identity management "Identity as a Service (IDaaS)", but just like any upcoming trend, it tends to be understood differently, explained differently and used differently depending on context. Burton Group provides a very concrete definition that focuses on the outsourcing of identity management, such as authentication, provisioning and attributes services. Dave Kearns has covered this topic extensively as well, under the context of "Externalizing Identity into the Cloud". My friend Nishant Kaushik defined the term in 2007 as "the notion of making identity management capabilities available as an infrastructure service to all applications in a SOA environment".
In a way, this reminds of the late 90's when the term identity management was making its foray in the world (yes I admit that I was an identity guy back then - lucky me!), and everyone had its own definition and everybody from Dun & Bradstreet to Access360 to Oblix provided identity management. And I think that the term is still misinterpreted today, though not entirely misunderstood, just like any normal teenager at this age.
So, one would wonder: why propose yet another definition for IDaaS? Well, I encourage you to keep on reading, as I think I will make my point clear, and hope to ignite good comments and discussion along the way.
With that: what is IDaaS? It is an approach to digital identity management in which an entity (organization or individual) relies on a service provider to make use of a specific functionality that allows the entity to perform an electronic transaction which requires identity data managed by the service provider. In this context, functionality includes but is not limited to registration, identity verification, authentication, attributes and their lifecycle management, federation, risk and activity monitoring, roles and entitlement management, provisioning and reporting.
The relevance, or perhaps novelty, of this definition, is that it focuses on the interaction of four elements: the entity, the service provider (which could be the entity in some cases), the specific functionality and the electronic transaction.
The Context of IDaaS
I believe that IDaaS as a concept has seen increased interest and coverage this year, in big part due to the impact of the global economic challenges which are forcing organizations to revisit its models for adopting and implementing IT initiatives that require identity management, as well as an increased emphasis in regulatory compliance and privacy awareness.
In any case, there are some important considerations regarding the definition of IDaaS that I would like to point out:
- It is not meant to be just a technical definition. And while the definition does not conflict (I would hope) with a technical definition or architectural approaches, it is important to think about IDaaS from a legal and jurisdictional standpoint as well. In this context, the definition of ownership, responsibilities and liabilities is significant to all parties involved in IDaaS. Tom Smedinghoff, a well-known contributor to the identity management industry, has created great content and led several initiatives that are bringing the legal aspect of digital identity management at par with its technical evolution, all of which is relevant to adopting IDaaS.
- The strength, rigorousness and thoroughness by which IDaaS is provided, should be measurable in an objective and demonstrable way, such that they can convey a specific level of confidence or assurance to the parties. This in turn will translate to a risk mitigation level that the parties can agree to be sufficient for a specific type of transaction. The Identity Assurance Certification Program run by the Kantara Initiative provides a very concrete vehicle to achieving this measurement.
- IDaaS should not be restricted or misconstrued as only applying to "cloud" based models. While IDaaS is particularly relevant for cloud-based services, IDaaS could also apply to on-premise models. In fact, I argue that it is in this area where the definition is most beneficial, as organizations can view its internally-facing (and possibly internally deployed) identity management infrastructure as identity services, allowing the demarcation of service scope and boundaries that will make outsourced, on-premise, cloud-based models or any combination therein more concrete, and easier valuate in business terms. The intention is not to confuse IDaaS with "Cloud Identity" or with "outsourced identity management", since the term could apply to all these cases.
- The concept should also not be restricted to enterprise IDaaS vs. consumer IDaaS, since the notion is basically the same. Evidently, the actors, the types of transactions, the levels of sensitivity in them, and other elements will vary greatly from enterprise to consumer environments, but the notion of how digital identity management applies to each could be thought of in the context of IDaaS.
Why is this even relevant?
My motivation to introduce this definition at this point is to attempt to set a common understanding of terms, allowing us to better understand the new trends, services and paradigms in identity management that are unraveling before our eyes. As I believe that a significant shift in identity management from a monolithic model to a true services-based infrastructure, has been at play for the past 2 years, with noticeable effects only in the past 6 months.
With this shift has come some degree of confusion in the industry among identity management in the context of cloud-based services (i.e. SaaS, Infrastructure as a service), identity federation (claims or assertion based) and the more traditional enterprise deployment models, to a point where they are at times seen as independent or separate; causing people to think of IDaaS as not relevant to the enterprise facing environment or mystifying it as another "cloud" term. And in some unfortunate instances this confusion has impacted the way an organization looks at implementing an identity management solution (either by limiting the range of options that it could look at or by widening it to include the wrong set of options).
I intend to demystify this concept a bit more in subsequent blogs, and attempt to bring more pragmatism around it by explaining how it applies to concrete scenarios. In the meantime, I appreciate your comments and reactions.