Blog

Identropy Launches Innovative Co-Sourced Identity & Access Management Offering

Today, Identropy, an Identity-enabled solutions provider, announced the public availability of its co-sourced Identity & Access Management (IAM) solution platform known as SCUID (Secure Co-Sourced Unified IDentity).  SCUID is a co-sourced managed services platform that provides a complete suite of Identity & Access Management services that includes Identity Governance and Compliance and Identity Lifecycle Management services – all managed and monitored by Identropy’s services for IAM operations management: SCUID Operations (formerly iMIS).   The co-sourced services are built on pre-configured virtual appliances, that can be deployed either on-premise or hosted in Identropy's private cloud -- a SAS 70 Type II facility that is connected to the client’s infrastructure based on a secure site-to-site VPN connection.

"With SCUID Operations, we are able to achieve both multi-tenancy and location agnosticity for our IAM reference architecture. This allows our customers the flexibility and deployment options that makes the most sense for their IAM infrastructure, while SCUID Operations will monitor the solution regardless of where it is deployed," said Frank Villavicencio, Identropy's Executive VP.  "Our SCUID Operations customers in Retail, Government, Healthcare and Financial Services have benefited from this proven reference architecture that we have developed from over 100 IAM implementations."

The SCUID Identity Lifecycle service is built on Identity User Provisioning software with 8 pre-configured use cases spanning automated employee on-boarding to workflow-driven non-employee provisioning.  Based on Identropy's extensive experience deploying User Provisioning solutions, the most common configurations and use cases were selected in order to substantially shorten deployment time in a tried and tested reference architecture. "We are confident that this new model will accelerate time-to-value for our customer, and will represent a paradigm shift in the identity marketplace", added Villavicencio.

For more information, visit our website at identropy.com or email us at info@identropy.com.

Advantages of a Hybrid Co-Sourced IDaaS Model

Earlier this year, I published a blog article entitled Approaches to Identity-as-a-Service (IDaaS) for Enterprise Identity Management.  In this article, I will focus on the advantages of one of the approaches discussed: co-sourced IDaaS (a.k.a.  identity management co-sourcing), and, more specifically, the 3 model or "Hybrid: on-premise and in the cloud".

Motivation

So, why focus on this hybrid co-sourced IDaaS model?  I predict this model will become the de facto approach to Identity and Access Management (IAM) in the future (in two years or so).  Here's why:

1. It provides an approach that is more palatable to the organization. It doesn't take everything to the cloud, or turns everything to a Managed Identity Service Provider (MISP). Rather, the organization will have options for how many, and which services, can be migrated to the cloud. This will resonate better with risk, security and compliance officers, who may have some reservations about the migration. It gives them time to get more comfortable with the MISP.
2. The model allows for more flexible integrations with internal identity assets, such as Active Directory or HR databases, which might not even be exposed to the cloud due to risk concerns. Having an on-premise footprint alleviates these concerns, and provides for an enforcement point in which data can be filtered, secured and transmitted with the appropriate level of risk mitigation. Likewise, this approach avoids the undesirable side effect of exchanging data files (typically via batch), which then increases the risk of data being leaked. The on-premise footprint (or appliance) can implement a message-driven data exchange model with the internal Identity repository and with the cloud-based Identity service.
3. From a connectivity standpoint, the on-premise footprint (i.e., the appliance) provides secure communication with the Identity service through the public or private cloud. It may provide caching and queuing to increase the reliability and responsiveness of the service and build high-availability and load-balancing logic, making it easy to determine with which Identity service to connect (provided the Identity service is deployed in a highly-available and hot-swap disaster recovery architecture).
4. Architected properly, it allows the MISP to scale its managed service model by being able to funnel existing and new services that can be offered to the same client by leveraging the existing architecture. In other words, adding a role management service onto an existing user provisioning service would not require deploying another appliance or opening new ports in the organization's network to be able to provide the service. The on-premise appliance would be able to syndicate these services transparently. This translates to less overhead for the organization (no additional burden on IT or the auditors) and for the MISP (no additional appliances and re-architecting needed)
5. It still achieves the goal of simplifying and reducing the IT footprint that the organization would need to deploy and maintain.

The Business Side

From the organization's standpoint, the co-sourced IDaaS model, in general, can alleviate the need for:

• selecting, purchasing, and depreciating IAM technology
• building, maintaining, and operating the IAM infrastructure
• customizing and integrating various products
• staffing, training, and retaining personnel to manage the IAM environment.

All this immediately translates to cost savings.

The MISP is responsible for building, integrating, deploying, and operating the Identity service that suits the organization's requirements.  This approach will reduce upfront costs (not needing to procure hardware and software, and their respective maintenance annuity), which are now blended as part of the managed service "lease."  Likewise, by not having to recruit, train, and retain specialized staff to operate the environment, the model expedites deployment timelines and reduces operational costs and risks to the organization.

In this approach, the MISP is involved in the delivery of the IAM solution, which is then governed by established parameters and service standards (i.e., SLAs).  Whether it's hosted on premises or outsourced (in the "cloud"), in the end, the organization sees immediate and measureable value for the services they purchase-in a predictable and simpler manner.

For the MISP, the need to reduce the implementation timeline and create the capability of a repeatable model forces it to streamline the deployment process and ensure that it is done with such quality that its' operation after deployment requires minimal involvement.  In the end, these elements accelerate time-to-value.  In a past blog post, I discussed time-to-value as one of the key points to consider in any IAM initiative.  It is a metric that is often overlooked - everything being equal you should look to shorten time-to-value for the organization. 

The MISP will be motivated to shorten and streamline implementation so clients can consume its Identity service(s) much more quickly. Clients will also be able to scale operation and profit from the MISP's efficiency. This distinct synergy in the co-sourced IDaaS model is worth noting: both parties, the organization and the MISP, are motivated to reduce the time it takes to be up and running.  This is why we believe that this deployment model will succeed, as it aligns more closely with the interests of the parties involved.  Moreover, the need to shorten the implementation timeline and create the capability of a repeatable model forces the MISP to streamline the deployment process and ensure that it is done with such quality that its operation after deployment requires minimal involvement.

The charts to the left compares, at a very high level, a typical flow of value and cost that occur in a timeline between the two models,  and illustrate why the co-sourced IDaaS model will exhibit a shorter time-to-value.

Furthermore, for current IAM initiatives, there is no longer room for soft ROI; hard dollar is king. Organizations need to think about how to measure value and ROI from IAM.  We see that in a co-sourced IDaaS model these metrics can be easily tracked and gauged at any given point in time.

Organizations can also benefit from implementing charge backs from IT to other internal organizations to effectively determine TCO, and possibly ROI, and from shifting their expenditure from capital to operation expense.

In the end, from a business standpoint, the MISP and the organization engage in a long-term contractual relationship, jointly committed to successfully operating an environment with tight controls on scope and complexity.  The net result is that the client measures value immediately and continues to see value on an ongoing basis, through relatively simpler and more transparent metrics.

I hope these points are thought provoking. Your comments are most welcome.

Are MSSPs the future of IDaaS?

Or is it the reverse: Is IDaaS the future of MSSPs?  That is the question...

For some time now, I have been talking about Identity as a Service (IDaaS) and discussed a few approaches to IDaaS for Enterprise Identity Management, which truly set a baseline for what we believe is the next paradigm in Identity and Access Management (IAM): the shift towards managed services, away from traditional Enterprise deployment models.

Are we talking about a paradigm shift?

I believe we are.  Let me illustrate with a few questions:

1. Have you been involved in, or responsible for, the deployment of an IAM solution?
2. Has this deployment succeeded in meeting the business objectives and stayed within the timelines and estimated budget?
3. Has your organization needed only one attempt to implement an IAM solution, without re-architecting, replacing technology vendors or system integrators, etc?
4. Is your organization able to measure the return on investment (ROI) on this initiative?
5. Lastly, was your ROI positive?

After over 12 years of experience deploying IAM solutions, large and small, I have seen only a small percentage of people who answered these questions in the affirmative. Even though the number has increased over the years, it is still not as high as most would want or expect, given the availability and maturity of IAM technology.

Why is this so?  Many respondents cite issues with the technology choices underpinning the solution. Others point to a lack of alignment and sponsorship between technology and business stakeholders. Some say that there were no clear business objectives and expectations were not properly managed.  A few venture that IAM solutions are complex and difficult to implement and underestimating their size or complexity proved a recipe for disaster.

All of these are valid reason.  But does this mean that most IAM solutions are doomed to fail?  The answer is not very encouraging if you follow "traditional" deployment approaches. To date, most if not all IAM deployments follow a scenario like this:

Faced with requirements from the business, IT selects a technology vendor, allocates the environment in which it will run (hardware, software, network, and data center), and in most cases engages a system integrator to help design the architecture, map the business requirements and processes, and implement the solution.  Once deployed, IT is then tasked with hiring, retaining, or developing the qualified personnel it needs to operate the infrastructure.  As we discussed in a recent blog post titled "Top 10 Common Pitfalls of an IAM Initiative", this combination of factors causes most projects to run longer and cost more and, in many cases, do not meet the business requirements they were meant to address. The organization is then left with a capital expenditure that needs to be recovered over time.  Therefore, IT embarks on programs looking to integrate more applications and absorb more environments (M&A, intranet, extranet, etc.)-and their success rate increases only marginally.  In many cases, attrition of the internal personnel further complicates the ongoing success of the deployment.

Sound familiar?  The fundamental issue with the "traditional" approach is that the organization's best interest is not well aligned with that of the partners it relies on to undertake the deployment.  The organization is at the center of the storm, looking at mediating and balancing the interests of vendors, system integrators, and, its own staff, who are typically not qualified to deploy an IAM solution or aware of its complexities.

This is why a new approach is needed-one that aligns more closely with the interests of the organization.

 In my view, this paradigm shift is the motivation for IDaaS.  One could also say that the economic conditions of the last two years, combined with the rise of the Software-as-a-Service (SaaS) model have been catalysts for this new direction.

But what is different about IDaaS?

The idea with IDaaS is that rather than having the organization strike a balance among the interests of vendors, system integrators and its own staff, an external entity acts as a trusted provider, entering a long-term relationship that is gauged by measurable results (i.e. SLAs, performance metrics, delivered milestones, etc.)

From the organization's standpoint, this model can alleviate the need for selecting, purchasing, and depreciating IAM technology; building, maintaining, and operating the IAM infrastructure; customizing and integrating various products; and staffing, training, and retaining personnel to manage the IAM environment, all of which will immediately translate in a reduction in costs.

The idea is to engage a trusted provider to build, integrate, deploy, and operate an IAM infrastructure that suits the organization's requirements. This approach should reduce upfront costs (not needing to procure hardware and software and their respective maintenance annuity), which are now blended as part of the managed service.  Likewise, by not having to recruit, train, and retain specialized staff to operate the environment, the model expedites deployment timelines and reduces operational costs and risks to the organization. For the provider, the need to reduce the implementation timeline and create the capability of a repeatable model forces it to streamline the deployment process and ensure that it is done with such quality that its operation after deployment requires minimal involvement. In the end, these elements accelerate time to value.

Under this model, the trusted provider is involved in the delivery of the IAM solution, which is then governed by established parameters and service standards. Whether it is hosted on premises or outsourced (in the "cloud"), in the end the organization sees immediate and measureable value for the services they purchase-in a predictable and simpler manner.

Well, this kind of sounds like an MSSP model?

Bingo. This is precisely our prediction: the IAM deployment model as we know it is already being transformed from a highly complex approach toward a simpler one. It does not mean that IAM technology is simpler; it just means that the deployment model needs to get simpler. 

"Everything should be made as simple as possible, but no simpler." - Albert Einstein

From my standpoint, this is just a natural evolution, and while it will take time for it to pan out, it is already at play, as evidenced by events like these:

• April 27, 2010: Verizon and Novell Unveil Cloud-Based Security Solution - an interesting quote from the announcement grabbed my attention: "Additionally, as part of this agreement, Verizon will be Novell's preferred identity and access management managed service provider."
• December 12, 2009: SecureWorks Expands its Global Operations and Services with the Acquisition of UK-based dns Limited - here are two relevant quotes from the announcement: "For ten years, dns has been delivering a wide range of security services to its clients, including an innovative Identity and Access Management Service"; and "SecureWorks is expanding the scope of its service offerings with the addition of dns' Identity and Access Management Practice which will benefit clients worldwide."
• May 14, 2007: Verizon Business acquires Cybertrust - and the quote: "Cybertrust's services include identity management, managed security services, vulnerability/threat management, security certification programs and a range of professional services..."

Similar events have been taking place for some time, such as IBM Managed Identity Services (part of IBM's Managed Security Services) and BT's Identity Administrations Solutions.

If you follow this logic, you will see that two paths are intersecting:

1. Established MSSPs are adding IAM to their model because they want to differentiate and grow their role as a trusted partner to their clients or are responding to client pressure.
2. IAM solution providers, and even software vendors, are evolving and embracing the SaaS model, and as such are starting to morph into MSSPs with a focus on identity, or as I like to call them: MISPs (for Managed Identity Services Providers)

Our prediction

Over the next three years, IAM will shift from the traditional deployment model (buy, host, deploy and operate) to an IDaaS model, making the latter the default. IAM technology will be mainly designed to enable IDaaS deployment models, and customers will most likely procure IAM via their MISSP of choice.

Identity Assurance, an everyday life issue (part 1 of 2)…

In this 2-part article, I hope to explain the importance of identity assurance in everyday life. I will first level set on terms and definitions in part 1, and then illustrate with real-life examples in part 2.

The notion of identity assurance is to establish, with a level of certainty, that the human being represented by a credential in an electronic transaction is in fact the alleged person. Whether you realize it or not, whenever you perform an electronic transaction, you are making some kind identity assurance tradeoff.

Identity assurance does not only apply to scenarios in the extranet in which consumers or users from one organization interact with systems in another. It also applies within the enterprise where you need to view identity lifecycle management holistically, as opposed to fragmented steps, such as provisioning, authentication, single sign-on, etc.; and how they contribute to creating and maintaining identity assurance.

My Personal History

In late 2006, I was first introduced to the issue of identity assurance as a trend in identity management.  It all started with the FFIEC's October 2005 guidance on Authentication in an Internet Banking Environment. It appeared on my radar as I was strategizing on the future of web access management and the product portfolio for which I was responsible. I was also wrestling with transaction assurance and access management 2.0. At the time I did not realize the profound impact that this concept would have on my career.

In late 2007, as I was managing a high-assurance digital identity service offering at a large global bank, I was introduced to Liberty Alliance Identity Assurance Expert Group. I joined the group as a co-chair which led to my current role as Chair of Kantara Initiative's Identity Assurance Work Group that is responsible for the Identity Assurance Framework. It works closely with the Kantara Initiative Identity Assurance Certification Program, which actually instantiates the framework in an actual program.  So, I guess you can say I have become an identity assurance activist.

It's All About Risk

In any electronic transaction where a human is represented, an implicit identity assurance tradeoff is made. A human may be represented in a transaction by providing a user name, email address, or simply by checking off a box accepting certain terms and conditions. The question is whether we are aware of or comfortable with the tradeoff. In all instances, you and the party with whom you are transacting are agreeing that your identity can be representing in this way for this transaction, and accept the consequences of what might happen if something goes wrong (i.e. your credentials are spoofed or compromised, or you chose to share your credentials with somebody that acts on your behalf and does something wrong).

The higher the sensitivity of the transaction, the higher the confidence (i.e. assurance level) you would like to have.  Therefore, an identity assurance level (AL) should map to the risk level in any given transaction.

All identity assurance documentation that I have read or been involved with converge on four basic levels of assurance:

• Level 1: Little or no confidence
• Level 2: Some confidence
• Level 3: High confidence
• Level 4: Very high confidence

OMB Memorandum M-04-04 illustrates this rationale from the perspective of the US Government. It effectively explains the application of identity assurance to transactions, considering the impact of something going wrong, and also the expected frequency of its occurrence. Below is a table I borrowed from this document that focuses on authentication.

Advice:  Be aware of the sensitivity of a transaction. Think through the mechanism employed to mitigate risk and if it is sufficient enough to convey the appropriate level of confidence. Consider the intersection of identity assurance with your data and risk classification.

It's Not Just About Authentication

Another important realization, particuarly for me given my background as a product manager, was that identity assurance is not just how strongly you authenticate someone. A number of factors come into play. Moreover, identity assurance, like other facets of identity and access management (IAM), is a lifecycle process.   An identity lifecycle includes stages ranging from registration (initial creation, identity verification, credentialing) to contextual access control (authentication, risk and activity monitoring, stronger authentication), renewal and termination.

An IAM solution must account for the fact that identity assurance decays over time and that lifecycle processes, such as renewal or termination, are necessary to either preserve the assurance level or eliminate the risk of a compromised identity.

Even though this concept may seem obvious, traditional IAM deployments do not incorporate identity assurance as a guideline, and thus rely on a static notion of identity.

This approach towards risk and identity assurance allows end users and organizations to gain trust in relying on online channels to conduct sensitive and higher-value transactions.

In my next blog post, I plan to illustrate these concepts with some real-life examples. In the meantime, I look forward to your comments...

Approaches to IDaaS for Enterprise Identity Management

Happy New Year 2010 to all. Best wishes in the year that just starts.

I will start this year's first posting by acknowledging Burton Group's (just acquired by Gartner) Bob Blakley September 30^th, 2009 vantage point titled: "2010 Identity and Privacy Strategies Planning Guide: A Market in Transformation", which has been an excellent reference in helping me shape some of my thoughts for this article. I think it is a great document with great insights on current trends in identity management.

My prior blog posting introduced a definition for Identity as a Service (IDaaS), setting the stage for this posting, which discusses models for deploying IDaaS, from the perspective of the entity that consumes the Identity service, in this case an organization (as opposed to an individual). The assumption will be that the entity and the service provider are two separate organizations, and moreover, two separate legal entities. In a way, this perspective is no other than the Enterprise identity management.

In addition, for this discussion, we will try not differentiating the kind of Identity services being provided (provisioning, registration, authentication, etc.), or which user population within the entity it is intended (i.e. employees, contractors, suppliers, customers or business partners). The idea is that the approaches should be applicable to all of them.

Defining Managed IDaaS

In this article's context, Managed IDaaS is an approach to IDaaS in which the entity employs one or more separate legal entities as service providers. The service provider is contractually bound to specific terms that define how the service is performed, and it governs its adherence to these terms through mutually agreed and measurable service level agreements (SLAs). In other words, Managed IDaaS, is the scenario in which an organization consumes Identity services from an external service provider. These services can range from operating a provisioning infrastructure, to verifying the identity of a person, to providing strong authentication or federated authentication credentials, to managing passwords;  and they can be provided both internally (i.e. within the organizations Intranet) or externally (i.e. through an extranet portal), and can physically reside on-premise or in the cloud, or a combination thereof.

Two main variants of Managed IDaaS are common today, and as Gartner forecasted, they should trend upwards in adoption within the next two years. They are mainly determined by who is responsible for and who owns what part of the Identity service infrastructure, which in many cases correlates directly to where the infrastructure component actually resides:

• Cloud IDaaS - where the service provider owns and operates the entire Identity service infrastructure, and provides it to the entity in a pure SaaS manner, without any sort of footprint or backend integration with the entity's IT infrastructure. Identity information is exchanged in an offline (manual or batched) manner.
• Co-sourced IDaaS - using Wikipedia's definition of co-sourcing, this is an approach in which the Identity service interacts directly or through some technical footprint with the entity's IT backend infrastructure (directories, repositories and other target systems). The entity and the service provider have a shared responsibility for building and operating the Identity service, the balance of this responsibility determines distinct scenarios, which we will focus in more detail in this article.

To better understand Managed IDaaS, it is useful to decompose it into building blocks. The diagram on the left provides a high-level structure for an Identity service, made up by three main functional areas:

Consumable Identity Service - this is the end point of the service, which interacts and integrates with the consuming entity, whether an end user interacting through a web UI or an application or repository that exchanges information with the service. This is the area in which the specific logic and functionality provided by the service is actually "wired".

Identity Management Stack - this is the middleware of the service; the software modules that provide the basic functionality to manage and process identity information.  The diagram shows an arbitrary sample of the software components that make up the identity management stack. It is not mean to be an exhaustive list, but rather a representative sample. Nishant Kaushik has done a great job explaining the identity services framework, which instantiate the identity management stack.

IT Platform - this is the technical backbone of the service. The basic IT computing infrastructure that is not specific to identity management, but generic to any IT service.

These three basic functional areas are useful in explaining how variants of a Managed IDaaS come to life, particularly co-sourced IDaaS.

Co-Sourced IDaaS

It is a Managed IDaaS variant in which the Identity service's consumable service interacts directly with backend (or back office) IT infrastructure managed and operated by the entity. And more importantly, one in which the entity and service provider enter into a partnership in which they share some of the responsibility in building, hosting or operating the Identity service.

The diagram below illustrates four common co-sourced IDaaS scenarios, which we'll discuss next. I admit that while I have spent time thinking about these scenarios, I do not think I have articulated them in a way that clearly delineates their boundaries (if any), so I am hopeful that by venting them out, I will get very good thoughts from you.

1. All on-premise, provider operated - when the entity owns the identity management stack used to build the service, as well as the actual IT platform; and the Identity service is hosted on the entity's premise where it integrates directly with the entity's backend IT systems in the Intranet. The service provider is responsible for configuring and operating the consumable Identity service. This model is a more "traditional" Enterprise identity management deployment approach, where an organization procures the entire IT stack, and hires an external integrator to build, and possibly operate the Identity service, according to defined requirements. The organization and the integrator establish service agreements which govern roles, responsibilities, response times, escalation procedures and son on.
2. Provider hosted and operated - where the service provider hosts and runs the entire Identity service, and integrates directly with the entity's consuming backend IT systems. This scenario is seen often at organizations that outsource their IT infrastructure and operations to an IT outsourcing service provider, and the Identity services are collocated and dedicated to the organization. From a connectivity perspective, the Identity services are typically accessed via dedicated lines (private clouds, private VPN). In this scenario, the service provider is often responsible for procuring and operating the consumable Identity service, the identity management stack and the IT platform. The outsourcing service provider and the organization establish service level agreements as well as licensing agreements which ensure that the organization is entitled to use the technology infrastructure require for the Identity service. This scenario is typically single tenant for both the consumable Identity service and the identity management stack functional areas.
3. Hybrid: on-premise and in the cloud - where the service provider hosts and runs the entire Identity service in an environment hosted in the cloud, and requires some technology footprint to be deployed on-premise at the entity's IT environment to effect the integration with its backend IT systems. The scenario is one where the organization "leases" the Identity service from the service provider, which includes the use of the on-premise footprint - say a virtual or physical appliance, and access to the actual Identity service which is hosted in the cloud. From a connectivity standpoint, the appliance provides secure communication through the public Internet, and it may also provide caching and queuing to increase the reliability and responsiveness of the service. The service provider owns and runs the Identity service backbone and may adopt a multi-tenant model. The organization and provider agree to service SLAs, which will also govern how the on-premise footprint is operated.
4. All in the cloud - where the service provider hosts and runs the entire Identity service in an environment hosted in the cloud and it integrates with the entity's backend IT systems without requiring additional technical footprint, leverage secure, open standards-based interfaces over the public Internet. In this case, the organization "leases" the Identity service from the service provider, and configures its backend IT systems to communicate directly with the service. The provider owns and runs the Identity service backbone and will most likely adopt a multi-tenant model. The organization and service provider agree to SLAs under an Application Service Provider model.

In future postings, we will discuss considerations and advantages of the co-sourced IDaaS model. In the meantime, I look forward to your comments.

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.

Identity Management Veteran Joins Identropy to Boost Execution on Managed Identity Services Strategy

Press Release

Little Ferry, NJ --- Frank Villavicencio, a known expert in the Identity & Access Management space, has joined Identropy as Executive Vice President to advance the definition and lead the execution of Identropy’s managed identity services solutions strategy and business model.

Identropy is known in the industry for its identity management consulting practice, which helps organizations create an identity management strategy and roadmap, deploy effective solutions, as well as its innovative offerings such as iMIS and IC2, which streamline the adoption of identity management solutions and mitigate their operational risks once deployed. “The addition of Frank Villavicencio, represents a significant milestone in the evolution of our existing offerings, as we gear to turn them into game-changing approaches towards deploying identity management solutions”, states Victor Barris, Identropy's CEO. “Our insights in the marketplace, validated by our many clients, have given us evidence that we are at the brink of a significant transformation in the Identity & Access Management space, as clients continue to move away from the traditional, enterprise deployment models”.

“I am thrilled with the opportunity to lead this important area of Identropy’s business strategy”, says Frank Villavicencio. “This disruptive innovation signals the shift to a new paradigm in identity management after a decade of incremental evolution, and I am glad to be joining an organization that embraces and is poised to capitalize on this change.  The adoption of managed service models, combined with Agile delivery methodology, and a focus on risk mitigation including operational risks, will immediately translate to shorter time-to-value for organizations, enabling them to truly take advantage of identity-enabled processes in a reliable, cost-effective and measurable way”. This is the focus of Identropy’s Managed Identity Services strategy.

Frank has more than 14 years of experience in Internet Security and Identity Management, spanning consulting, large implementations, business development, sales, product management and the invention of two awarded patents in the area of web access management, as well as published papers and public speaking engagements. He is the Chair of Kantara Initiative’s Identity Assurance Work Group, which is responsible for the Identity Assurance Framework (IAF), an industry standard for measuring and conveying identity assurance within digital identities. He has been part of Citigroup’s Managed Identity Services Product Management team, focusing on strategic partnership and business development programs at a global level. Prior to Citigroup, Frank worked at Oblix, Inc. and later at Oracle Corporation, after Oracle’s acquisition of Oblix. Frank has gained an international reputation for his exceptional leadership abilities and proficiency in the identity management space.