Blog

What's Your Identity Management Consulting Firm Hiding?

Based on my experience, most Identity and Access Management (IAM) consultancies - even the "Big 4" - tend to keep clients in the dark.  Due to the complexity of IAM projects and multiple stakeholders, it's easier to hide the gory details of a project gone wrong until its too late.  Unfortunately, this approach has given the IAM services industry a black eye. 

As an organization, we are big believers in transparency for our clients. Transparency not only aids teams to work through project curve balls, but it also empowers the teams to spot risks collectively in order to prevent them from ocurring in the first place. 

As I write this post, Identropy is now in its' fourth month of everyday usage of our Project Management Information System (PMIS). When I initially joined the team, we were using a mix of disparate tools: SharePoint for document management, a Time Tracking application, MS Project and Excel files for resource and expense management. Individually considered, our disparate parts did what they were supposed to, although none of these tools really talked to eachother.

In our quest for increasing transparency for both ourselves and our clients, the lack of integration of our various systems caused significant overhead for our PMs.  They had to spend time to create the level of transparency we wanted our clients to have.  In order to address this inefficiency, we decided to look for a better solution: a single place for our customers to have total visibility into our IAM project progress, cost, risks, documents, etc.

Simply stated, Identity & Access Management projects require strong and active project management. And while technology is never a good substitute for solid processes, our experience is that an effective Project Management Information System (PMIS) can put your IAM project on steroids by increasing transparency into the state of the project.

Since I had experience using an Enterprise wide PMIS tool, I led the effort of defining our requirements and identifying likely candidate solutions. In one of my earlier blog postings, I wrote about the importance of a good Requirements Traceability Matrix. So, the first thing I did was begin working with my team to start evaluating just what requirements we really had for a PMIS. I constructed an RTM and began consolidating requirements into various components such as "Financial Tracking" "Scheduling", "Calendars", etc...

Our key criterion boiled down to 3 major points:

1. Proper Task Sequencing: In a typical IDM project, one task must drive another. Without this, you simply have a glorified to-do list, which any IDM PM knows is the kiss-of-death for the project.
2. SaaS Based Solution: Identropy is a zero IT footprint company. That means, unless absolutely necessary, we don't have anything on our premises.
3. Integrated Time Tracking, Doc and Expense Management: By integrating all of these components, we would have greater insight into projects, resource utilization, and how much we were spending.

The fun part in performing requirements assessments is discerning marketing hype from reality. (We have a lot of experience doing this for our clients when selecting an IAM platform!). The finalists demonstrated complete packages in terms of polish, solution feature sets and, to some degree, cost flexibility. Ultimately, Identropy chose Clarizen to partner with to provide our PMIS solution, for pretty much the same reason most organizations select Identropy as a partner. While the Clarizen solution is top-notch, the overriding-factor was and still is the people and their philosophy. From our account rep (Jacqueline, call her if you need a PMIS!) to our product support folks (Gil and Josh), it would be almost impossible to find people who truly care as much about honesty and earning a client's business as they do.

The impact of the overall solution has been great. Our clients have welcomed the increased visibility, which has allowed us to forge a closer partnership with them. It has increased communication between consultants, resulting in fantastic conversations regarding our implementation methodology. Lastly, it has served as a differentiator for us in front of potential clients that shows the practical angle of our corporate philosophy regarding transparency.

A Windfall for Identity Assurance

First off, I would like to would like to express my sympathy to those affected by the terrible earthquake that hit Chile this past weekend.

Envio mi palabra de aliento y de optimismo al pueblo Chileno. Tengo muy buenos amigos Chilenos y a todos les deseo lo mejor en vista de estas circunstancias, a sus familias y a todos los afectados... Las cosas de Dios son sin duda alguna indescrifrables.

In this blog post, I would like to share with you some recent developments in the world of identity assurance, which as you know from my recent blog posts: "Identity Assurance, an everyday life issue" part 1 and part 2, is a top of mind issue for me and for us here at Identropy. Quite frankly, I could not hope for better timing for these blogs to come about.

On Friday February 26th, 2010 the US Federal Government's Identity, Credential, and Access Management (ICAM) Trust Framework Evaluation Team (TFET) reviewed Kantara Initiative's latest submission and granted it Provisional Approval as a Trust Framework Provider at Levels 1, 2 & non-crypto Level 3 under the Open Identity Solutions for Open Government program.  The removal of the provisional status will hinge on the release by TFET of additional guidance for assessors concerning privacy and Kantara's adoption of this guidance.  

This is for me an extraordinary milestone, not only in my role of Chair of the Identity Assurance Work Group, but as an identity assurance activist altogether.  Kantara submitted its application for the US Federal Government adoption of the Identity Assurance Framework (IAF) in November of 2009. Prior to that date, the IAWG has been working very hard, collaborating with Kantara and the Assurance Review Board (who oversees the Kantara Initiative Identity Assurance Certification Program) to achieve this important goal (albeit still under provisional status).

The significance of this milestone is that it represents an important step towards fostering the adoption of identity-enabled Government services at known levels of assurance, relying on identity credentials issued and managed by non-Government parties (referred to as Credential Service Providers in the IAF). It will create the right conditions for the certification program to be adopted in real-life scenarios and for the industry to benefit from a proven, best-of-breed certification program that effectively enables interoperability and trust. This means that the IAF will not be just a "paper" standard, incarnated in a compendium of documents, but an actual technology-agnostic program that organizations can certify against.

With the adoption of risk-based models, identity federation can achieve Internet scale, and facilitate public access to online information at specific levels of assurance.  With adoption will also come economies of scale and further collaboration and interoperability across industries and Governments.

As someone who has been involved in identity management and identity assurance for quite some time, I cannot help but feel excited about the times I live in, and optimistic about what is to come.

I do anticipate and hope for more endorsements of the IAF in the near future by other organizations, and more importantly, the start of a paradigm shift in the way we all think about identity, both within the Enterprise and in a federated environment.  Ultimately, this path will allow the identerati to focus on the real end goal: delivering identity-enabled solutions and services with the level of trust and confidence that is appropriate for the transactions being performed.

But this is just a first step...

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

In part 1 of this 2-part piece I introduced and defined some of the terms relating to identity assurance. In this last piece I intend to illustrate identity assurance's intersection with real-life through some examples.

Identity Assurance in the Enterprise?

Some interesting considerations come to mind when thinking of identity assurance within an Enterprise Identity and Access Management (IAM) context. I will illustrate with two scenarios:

1. In the US, organizations need to follow the Employment Eligibility Verification or "I-9 Form" process for their employees. This is a minimum baseline, which meets AL4 (assurance level 4) requirements from an identity proofing standpoint. In some cases, many organizations, obligated by regulation in a specific industry or by the responsibility level the individual is assuming, perform background checks and other due diligence steps to help them increase the confidence in the individual's qualification for the job. Evidently, they are not driven by an identity assurance need but by other needs (e.g. AML - US Patriot Act compliance requirement in banking). This need results in a high-quality identity verification process for employees, which once entered into an HR system can be leveraged for other identity lifecycle and identity-enabled processes.
   
   But the same cannot be said about other types of employees such as contractors within the same organization. In many cases, these identities are managed by groups outside of HR, and are not obligated to follow as strict a process to register.
   
   In most cases, employees and contractors end up with an entry in the organization's Active Directory, from which they get assigned a username and password - an AL2 authentication method. As is often the case, these AD credentials are used to control access to a large number of systems and applications, ranging from a low to high level of sensitivity. In other cases, users (employees or contractors) are issued VPN access, with a 2-factor authentication credential - soft or hard tokens,  all the same either AL3 or AL4 authentication methods. This is so the user can access systems remotely in a secure fashion, since internal system's sensitivity level is deemed to increase when accessed remotely. But, in all such  cases, the organization is not effectively increasing the identity assurance of contractors. Even with strong authentication credentials, the risk level has not effectively gone down.
   
   
2. An example introduced in my blog post of January 25, 2010, a client has a request/approval process in place to manage the issuance of access cards (in this case, with no picture ID) to various facilities and sites. When an employee first comes onboard, their identity is vetted against information in HR in order to be issued an access card. The request must be approved by two management levels. Now, since the process often takes a few days to complete, some managers tend to hold on to the access card from a departed employee, literally keeping them in a drawer. When a new employee comes onboard, the manager recycles the access card and, by doing so, increases the employee's productivity by providing her with an access card without any delays, but all access activity and access authorization is based on the departed employee's information. The organization is now incurring significant costs to ensure that access to its facility is tightly managed, but the process for ensuring that a departed employee event triggers the deactivation of the access card is not well enforced.
   
   So in the end, this imbalance in identity assurance costs the organization money and does not really mitigate the risk it was intended to.
   

I hope I have convinced you that you are making identity assurance tradeoffs in your internal environment today. As you internalize identity assurance as a tenet  in your IAM program, remind yourselves of the importance of data classification and application sensitivity ranking, so you can tie identity assurance more effectively.

Advice: Do not make identity assurance a burden or yet another heavy set of requirements to deal with in your already complex IAM initiative, instead, think about it as a compass, or a tool that can help you make decisions around complexity, cost and risk. The point here is to ensure that your effort and investment is balanced in light of your requirements. Otherwise, you may be wasting precious dollars. Ask yourself: am I spending too much in authentication technology and too little in the process of ensuring I know who the person is? Is it the reverse? When you deploy single sign-on (SSO) solutions for your applications, what AL can you reliably say you are conveying or providing to them? Should they all have SSO?

Another Everyday Life Example

My friend Tom Smedinghoff recently informed me of this case: The Prudential Insurance Company of America, v. Dukoff et al (December 18, 2009), which was of particular significance for me in the context of identity assurance. It deals with authentication requirements for an electronic signature in an online insurance application. 

Basically, Prudential wanted to deny coverage under a group life insurance policy, and was trying to use allegedly false statements that appeared in the electronically signed online application as the basis for doing so.  The insured argued that the online application did not contain a valid electronic signature under the NY Electronic Signatures and Records Act, so, therefore, the allegedly false statements in the online application could not be used to deny coverage (since NY law prohibits insurance companies from using a statement made by an insured for purposes of contesting the validity of the insurance "unless it is in a written instrument signed by him").

 In this case the insurance application was submitted through a standard Internet click-through process that is normally considered a valid signature.  Yet the court focused on an opinion of the Office of General Counsel for the State of New York Insurance Department, which stated as follows:

Generally speaking, a checked box on an electronic form on the Internet constitutes a valid electronic signature in New York if the "electronic ... symbol or process [is] attached to or logically associated with [the] electronic record and executed or adopted by a person with the intent to sign the record,". . . provided that the insurer, agent or broker using such technology to transact business is capable of verifying that the person providing the electronic signature is actually the party to be charged. Without such verification measure in place, the Department would not consider a checked box to be a valid signature

 Relying on this opinion, the court held that in order for an insurer to use statements made in an online application to support its fraud lawsuit against a claimant, the company must have had sufficient authentication processes in place to make the signer reasonably identifiable.  While the court agreed that the signature itself did not need to identify the person signing, it held that "Prudential may use statements made in the insurance application to challenge the insurance contract's validity only if Prudential could reasonably identify the person who made them."  In other words, the court required that Prudential adequately authenticate the identity of the signer of the application.

 This real life example shows that:

• Identity assurance is truly an everyday issue with real life consequences
• Identity assurance is more than just authentication
• Even a simple checkbox on a web page has a direct tie to identity assurance

I am interested in your thoughts about these issues, and how your views of identity assurance affect your IAM initiatives. I am particularly interested in other real life examples...

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...

Considerations for an Identity Management Initiative in 2010

First off, I would like to express my sympathy to victims of the terrible earthquake that hit Haiti. I can only wish that the rescue and recovery efforts yield positive results.

Thanks to the recession, we have learned a lot (or so we would like to think) on the importance of sound business decisions, have we not?

This blog post is my attempt to bring some of the lessons learned, along with scar tissue, that I have been able to sum up from the last 24 months, as it relates to identity and access management initiatives. Last year, I spent time reading some Harvard Business Review articles, and recall reading a blog post titled: "6 Lessons Learned in the Downturn" by Anthony Tjan, which were very influential in shaping my thoughts for this post.

At the risk of stating the obvious, I would start by saying that the last 24 months have forever changed the way in which Identity initiatives will be carried forward.

It is clear that identity and access management systems are, more than ever, critical parts of any IT infrastructure. Organizations will always need to grant application and system access to those who need it and eventually remove that access once it is no longer needed. This is a recession-proved observation. The circumstances of today's economy highlight the need to tackle these activities in a more efficient, transparent and scalable way, and in most cases, automation is about the only choice you've got. Manual labor is way too expensive today, even when outsourced. This should be an encouraging statement for any identirati.

5 Lessons Learned

Below are five points that best capture the essence of this change.  These are based on experience working with clients across many industry verticals:

1. Your dollar needs to go a much longer way than before - If you even have an approved budget, you really need to maximize the value you will get from your initiative, and be ready to show how. Consider getting a second opinion before you buy new IDM technology. Ask yourself some questions:
• Have you done proper due diligence?
• Do you or your team have the cycles to invest in carrying out the proper due diligence?
• Are you relying only on what the vendor says or what you read on an analyst report?
• Do you have enough insight on how to negotiate with the vendors you have selected, based on what is important for your initiative?

We have seen from experience that even a nominal 2-week investment in an Identity Management Workshop that assesses your current state, identifies business drivers, high-level requirements, and formulates an implementation roadmap can go a long way.

A case in point: One of our clients allocated $750,000 in budget to acquire IDM technology in 2009.  Before moving forward, they invested in a workshop and in the end, identified a set of previously unknown requirements and ultimately saved 40% ($300,000) in their purchase, all within 8 calendar weeks. Considering what they spent on our services, this is an ROI in excess of 450%. Not bad in any type of economy if you ask me.

2. Minimize capital expenditure if you can - Consider lease vs. buy scenarios. The maturity of IDaaS today provides options for customers to avoid procuring software and hardware products that require capital expenditure, and instead consume them on an on-demand basis as an operating cost. This of course will maximize your cash-at-hand. Evidently, not all of your identity and access management needs can be met with an IDaaS approach, at least not today, but I would argue that 24 months ago this was not even an option to consider. There are several approaches to IDaaS, which can be appropriate to your initiative. It may be worth exploring these and engaging with providers that specialize in these kinds of models. Not all organizations are ready or comfortable with an all-in-the-cloud approach, but there are managed services models that work on-premise that should be explored.
3. You have to have metrics - For identity and access management initiatives, there is no longer room for soft ROI; hard dollar is king. As you define your Identity initiative, you need to think about how you can measure value and ROI to the organization. For some organizations, which adopt internal chargeback models for managing budgets, this should be relatively easy. The idea is not to stop at simply measuring costs, but ensure that you are measuring returns. In a way, try to make your metrics meaningful to the lines of business that you support (i.e. your internal clients). A metric that is often overlooked is time to value - everything being equal in cost, you should look to shorten the wait until you can show measurable value to the organization. In practice this will help you decide how you undertake your initiative. Maybe shorter phases are better than longer ones. Perhaps rather than a pure waterfall project management approach, you start to introduce agile methodology concepts. We have seen initiatives whose budget is cut in mid-flight. Even though you cannot fully prepare for this, you want to consider what you will show for if it ever happens, and whether or not delivering value early is the key to preventing your funds from being cut in the first place.
4. Let's demystify identity management - This may get controversial, but after 14 years of experience in IDM, I would like to demystify it. I agree that IDM is complex, requires specialized skill sets, and above all, is unforgiving if you do not have the right experience, but at the same time it is not unattainable, and settling for less is not the right posture. There are many ways to meet compliance requirements, even if you have not automated all of the access granting flows in your environment.

I applaud the advent of identity activity monitoring (the term we like to use to describe this new trend) in 2009, and while the analysts have not yet coined a particular name for it, there is a great report by Gartner's Mark Nicolett and Earl Perkings that focuses on this area, separate from just SIEM or just IDM, more as a separate niche in its own right.

I intend to further discuss identity activity monitoring in a future blog post, but for now, I would describe it as an approach to tracking user activity in various IT systems and applications that is correlated to the definition of a digital identity; thus creating a closed feedback loop that allows you to more confidently determine if your IDM controls are effective, regardless of whether they are automated or manual. In this way, organizations have a way to extract value out of lazy assets (such as application, database or system logs), which otherwise are used only for security event monitoring, and leverage them to increase visibility into what users are doing within the IT infrastructure. This is a very clever and effective way to approach some of the compliance requirements that Identity initiatives often try to address, in a faster and cost effective way. Moreover, it does not conflict with a traditional IDM implementation, but rather complements it.

5. Understand and embrace identity assurance - this is not limited to scenarios in the extranet in which users from one organization interact with systems in another - scenarios that some would deem esoteric and not as business critical. Even within the same organization, you need to pay attention to identity lifecycle as a whole and not just as discrete steps: provisioning, authentication, single sign-on, etc. Consider the intersection of identity assurance with your data and risk classification, and ask yourself: am I spending too much in authentication technology and too little in the process of ensuring I know who the person is? Is it the reverse? Strong authentication alone is useless from an identity assurance perspective (a good friend assures me that a well-trained Labrador could figure out how to use a smart card - although I have not seen the documentary on TV yet). The point here is to ensure that your effort and investment is balanced in light of your requirements. Otherwise, you may be wasting precious dollars.

To illustrate, here is a real life example: a client has a request/approval process in place to manage the issuance of access cards (with no picture ID) to various facilities in their organization. When an employee first comes on board, to issue an access card, they undergo a process of vetting their identity against information in HR, and that the request that has been approved by two management levels. Now, since the process often takes a few days to complete, some managers tend to hold on to the access card from a departed employee, and literally keep them in a drawer. When a new employee comes onboard, the manager recycles the access card and increases the employee's productivity by orders of magnitude, but all access activity and access authorization is based on the departed employee's information. The organization is now incurring significant costs to ensure that access to its facility is tightly managed, but the process for ensuring that a departed employee event triggers the deactivation of the access card is not well enforced.  So in the end, this imbalance in identity assurance costs the organization money and does not really mitigate the risk it was intended to.

I would love to hear comments and feedback on these points, particularly if you disagree.

Identity Assurance in the Nationwide Health Information Network (NHIN)... a cross roads of sorts

On Thursday January 7, 2010 (last week), I had the privilege of representing Kantara Initiative, in my role as Chair of the Identity Assurance[1] Work Group (also proxying for the Healthcare Identity Assurance Work Group) as a panelist in the Nationwide Health Information Network (NHIN) Workgroup hearings.

NHIN focuses on the definition of standards, guidelines and specifications on both technology and legal areas to enable the secure exchange of health information over the Internet. The focus of last week's session was authentication.

It was a great experience for me, particularly given the significance that NHIN's efforts will have in the way healthcare services are provided in the US over the next few years. The session made it clear that we are reaching a convergence of various efforts in identity management, which have reached the maturity level needed to address very real and critical business problems, and that the time to execute has come. Many of these efforts have been evolving over many years thanks to extraordinary contributions and leadership in both private and public sectors. This realization conveyed a sense of purpose and responsibility that quite frankly was not evident to me until the session actually started. Yes, I realize that at times I get very existentialist.

The format NHIN adopted for the hearings was very effective. It started with a viewpoint from US Government panelists followed by two sets of private sector panelists (I was part of the last round).  My fellow panelists did a really good job of providing their viewpoints in a clear and focused manner, and engaging in a very productive and dynamic round of Q&A after each round. This format made the sessions more productive, covered a wide range of viewpoints, and also helped identify themes and synergies. I commend NHIN on this.

Transcripts of the entire session, including audio voice-over and written testimonies, are available online. Also, Kantara published my written testimony in their blog area.

In this blog post, I intend to provide my summation of the event, and speculate on its potential outcomes.

Salient points

1. Panelists discussed the definition of authentication and reached a common understanding. In the context of the panel, authentication consisted of three distinct processes:
   • Proofing or verifying an identity,
   • Issuing a credential to the individual once her identity was proofed, and
   • The real-time event of confirming the validity of the credential as a digital proxy of the individual during a digital transaction.
   GSA's David Temoshok clarified that this definition excluded authorization - the ability to determine the kind of operation or data the individual can access.
2. I believe that the various panelists, including myself, converged on the notion that different assurance levels, as defined by NIST SP 800-63, provided a proven and practical approach to addressing different transaction risk levels. They also agreed that there is not a "one size fits all" approach that can address the broad range of use cases in scope for electronic healthcare. The discussions centered around the need to classify transactions and applications based on the risk profile, and avoiding the polarization on the highest assurance level for most use cases since it may be excessive and overkill.
3. Some recommended to NHIN existing frameworks that have been in use and proven for many years should be leveraged, rather than creating a brand-new, healthcare-centric framework for authentication. Leveraging existing Government programs and partnering with private sector players will help NHIN reach its goals in a more scalable and faster manner. NIH's Peter Alterman recommended that NHIN avoiding creating a healthcare-specific framework, highlighting the benefits of adopting cross-industry, best-of-breed standards.
4. There were great discussions on how to pragmatically reach the adoption rate required for the programs that HHS is driving forward. I particularly enjoyed the perspective provided by David McCallie, from Cerner Corporation; specifically, the statistics that show that in their network of 8,000 facilities, ~2,100 hospitals, 3,300 physician practices, 30,000 physicians, 500 ambulatory facilities, 600 home-health facilities, and 1,500 retail pharmacies; less than 30% of the systems use any form of SSO, and that provided the choice, less than 10% of the system adopt any sort of strong authentication technology. David also explained some of the challenges involved in achieving interoperability and federation across disparate system which were not designed to cross reference, and how much effort is truly involved in effectively mapping identities across different organizations.
5. Peter Alterman pointed out that Assurance Level 3 (AL3) is the minimum required to protect transactions that may expose personally identifiable information (PII), according to the Privacy Act. Later, Anakam's J Brent Williams talked about the ability to provide AL3 solutions that can scale both in terms convenience and cost, which can reach high levels of adoption, and are already in use at some large Government internet facing services. SAFE BioPharma's Mollie Shield-Uehling, made good points on the use of antecedent identity proofing as a scalable approach to AL3 remote identity proofing, based on SAFE's experience in the pharmaceutical community. My viewpoint on this topic was that AL3 should be demystified from being unaffordable and overkill, to being more attainable nowadays, particularly with remote identity proofing options, as well as evolving options for two-factor authentication options that could leverage mobile phones as authentication devices.
6. Brent raised two very good points that are worth mentioning:
• There are scenarios in which being able to provide identity proofing at a specific level of assurance level, but not necessarily having to issue a credential at that level or at all, will be beneficial, especially in cases in which a patient is granting permission to a physician to access her own electronic health record.
• PKI and SAML based authentication should not be viewed as orthogonal or in isolation in the context of identity federation and assurance levels. They are different ways to conduct and carry an authentication event, but in practice, they are techniques for conveying an authentication token. The real challenge in federating comes after the token is consumed, and particularly how the identity is actually "enrolled" in the target application (relying party).

My thoughts about the outcome

This was a worthwhile session with valuable insights and a broad range of important perspectives that rarely get discussed in a single sweep. I am very optimistic about the direction that NHIN could take in the aftermath of this event, and my read on some of the deliberations by the NHIN work group following the hearing fuels that optimism. My hope is that we do in fact see the convergence of approaches in healthcare that will allow for a faster pace of evolution and adoption, rather than a separate, healthcare-specific approach to authentication that may prove too ambitious and demand much longer timelines.

Here are my speculations on what may come out of this:

• NHIN will not reinvent the wheel in the area of authentication, but rather provide guidelines that leverage existing programs, such as the Federal Government's Identity, Credential, and Access Management (ICAM). This direction will help NHIN to increase adoption and use of digital credentials at various levels of assurance, by partnering with both the government and the private sector, thus removing barriers to entry and immediately tapping into established networks and communities that already have large numbers of credentials issued. It will allow the programs to hit Internet-level scale much faster.
• NHIN will focus on mapping various use cases and transactions to specific risk levels, equating them to assurance levels. It will also provide specific guidelines that will foster the development and rollout of digital solutions that leverage identity assurance within healthcare. These guidelines will lay a foundation for interoperability and risk-based models for these solutions.
• NHIN will define minimum assurance level requirements for its most critical use cases. For instance, NHIN may require that physicians obtain at least one AL3 credential that complies with an accepted identity assurance framework to be able to digitalize common transactions. It may focus on scenarios in which a credential may need to be upgraded from one assurance level to the next.
• NHIN will define acceptable models for performing identity proofing conforming to assurance levels for its most common actors. The idea here will be to clearly define options available to a physician for getting their identity proofed prior to obtaining credentials; likewise, to define acceptable models for how patients will get identity proofed [and credentialed], whether it is a responsibility that can be delegated to the patient's physician or some other stakeholder in the use case.
• Several requirements that NHIN will define for authentication will help advance and evolve existing identity assurance programs both in the government and private sector, as there will be new services or more granular scenarios that will require special handling. Having said this, I predict that these requirements will not be specific to healthcare. Instead, they will have applicability on other industries. A good example will be the need to separate identity proofing from credentialing as consumable rather than encapsulated services.

I would love to hear your comments and feedback.

---

[1] Identity assurance, in an online context, is the ability for a party to determine, with some level of certainty, that an electronic credential representing an entity - whether a human or a machine, with which it interacts to effect a transaction, can be trusted to actually belong to the entity.  In the case the entity is a person, identity assurance is the level at which the credential being presented can be trusted to be a proxy for the individual to whom it was issued and not someone else.

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.

More Thoughts on Identity Management Cloud Vendors

Matt Flynn has put together a list of vendors in the Identity & Access Management space who have a "cloud offering," and Identropy was included on the list for our IC2 offering.  Matt described IC2 as:

Identropy IC2 - Identity and Access Management solution for SaaS applications. Leverages existing Identity infrastructure and work flow to provision accounts to cloud applications.

Here are my 2 cents: IC2 has less to do with Access Management (or traditional WAM) and more to do with Provisioning.  In simple terms, it's a way for companies that already have a provisioning system in place that manages users for internal applications, to just plug into IC2 to extend management to SaaS applications (or technically speaking, any web application).  So basically - as of today, IC2 is geared towards customers that already have Identity Management software in place.

Other vendors, such as Conformity (from what I know, Conformity, please keep me honest) have taken a different approach. They have a complete provisioning system in the cloud, including workflow, connectors, policy engine, roles, etc.   So this approach puts them in the position of going head to head with existing IdM vendors, or target SMB clients who are searching for a provisioning system, but don't want the administrative overhead.

Identropy has take a different approach to the problem.  By speaking to our existing customers (who all have provisioning systems in place, so our market research is biased! :), we saw a need for extending out user management (onboarding, offboarding, etc.) to SaaS applications.  These customers would much rather leverage the infrastructure they spent a million dollars building rather than rip and replace the solution for a total cloud offering for Saas Provisioning and User Management.

An SPML gateway to the cloud seemed like the natural solution.  It abstracts the technical details of creating custom connectors from customers.   They also don't have to manage the connector, and it gets them up and running in no time, given that we already have a connector in place for the SaaS application in question.

Identropy Launches an Identity Gateway for SaaS Provisioning

After countless hours of working with a few of our beta customers, I am proud to announce Identropy's launch of IC2 (or IC squared), which stands for Identity Connector for the Cloud.

You can read more about it here, but the basic idea is that it's an SPML gateway (offered in both a hosted and on-premise model) that your existing Provisioning solution can plug into in order to extend provisioning out to your SaaS applications.

The coolest part of it is that as our SaaS connector library grows to cover more and more SaaS applications, all of our clients can leverage the same code base. Service offerings are great that way!

In the following weeks, we'll make sure to continue posting to give you some of the rationale for developing the solution, and a bit of a behind the scenes look into what we are doing here at Identropy. In the meantime, we'd love to hear your feedback.