Wednesday, May 19, 2010
Thoughts on Adoption of Federated Identity Technologies
In conversations with Prateek Mishra, Vadim Lander, Kim Cameron and others over the last year or so, many are struggling to understand why federated identity technologies aren't being rapidly adopted. I figured I would share a few thoughts as to why...
Many people are aware that one of my current activities is in figuring out how to bring federated identity technology to the property & casualty insurance vertical, specifically targeted at independent insurance agents. In order to provide a little context as to my approach, I figured I should start with an overview.
An independent insurance agent can do business with a variety of carriers ranging from Travelers, AIG, Geico, Liberty Mutual, Progressive, OneBeacon and so on. Each of these carriers will have their own policies related to how often a password should change, its complexity and how often a previously used one could be reused. An independent insurance agent could have business relationships with 30 carriers or 300 carriers depending upon its business focus.
So, one can quickly conclude that this business model brings lots of challenges to end users in managing their passwords. Now consider why it is important for it to be done properly as a consumer.
Consider your interaction with an insurance agent where you want to get a homeowners and auto insurance quote. The agent will of course want to know lots of personally identifiable information such as your drivers license to ensure you are a good driver, your social security number such that they can do a credit check and of course may desire your credit card as a method for paying for the policy.
This insurance agent will want to know how far you drive to and from work which means he also may have a strong sense as to when you aren't home. He may know about all the goodies in your house especially items that have high street value ranging from jewelry to furs.
So, let's say you have your trusty policy in hand and get into an auto accident where you smack your head bleed all over the dash. Their of course will be a claims file containing medical information. In summary, the insurance ecosystem has more information that consumers are otherwise blissfully ignorant about.
Most people are worried about healthcare data and leakage. It has always been my opinion that this matters less than insurance. Ask yourself, which would be worse, someone knowing that you have erectile dysfunction or as Paul Madsen would say, your wife learning about you insuring a car she didn't know about...
Let's start with the premise that the business controls all the funding for IT. While a business person can understand the challenges of having too many passwords and probably could calculate support costs associated with this worst practice, they probably couldn't articulate a vision that sounds anything like what federated identity solves for.
Taking this thought one step further, IT generally speaking follows traditional habits. If a business analyst were assigned to capture requirements around federation such that this feels like a traditional IT project and top-down driven, what would they capture? Do you think most business analysts have a clue as to how to capture business requirements around federated identity? Most business analysts at best are barely capable of capturing basic security requirements for applications they are familiar with.
So, does this get connected by enterprise architects? The answer is maybe, but ask yourself what evidence exists that says the vast majority of enterprise architects even have security (other than compliance) on their radar? Enterprise architects tend to travel is certain circles. When was the last time you went to any conference on enterprise architecture where federated identity was discussed?
So, we can conclude that top-down more often that not will be a fail, so let's look at it from another dimension. Since the independent agent would want each carrier to implement federation capability consistently, how would they organize a community around this? Are they properly equipped to even put pressure on carriers to ensure consistent implementation?
Another lens would say that carriers should network with each other. Ever heard of Elliot Spitzer who believes that these types of interactions are collusion-oriented? Even if Attorney Generals decided to not be an impediment, how would one person in enterprise A even know to find the right person in enterprise B? The person in enterprise A could do basic research and attempt to contact the business but understand that human nature says that most people will not forward things to others until they understand it themselves. We also concluded that federation is a challenge for business to understand. Does person in enterprise A spend his time on educating business customers in enterprise B? What CEO in their right mind would allow this to happen?
OK, so you are probably have concluded we haven't leveraged vendors to help us with this challenge. In order for a Microsoft, Oracle, Ping Identity, RSA, etc to assist with this, they first must understand what your business is. I went down this path myself and found that all of the vendors knew I worked for an insurance company but none of them could tell within their own CRM systems what kind of insurance company I work for. They couldn't distinguish between P&C, Life, Health, Re-insurance, etc which is important to the use-case.
In this model, Aetna may have merit in coming up with standards used in health insurance along with WellPoint, Cigna, UnitedHealthCare, etc but it wouldn't make sense for Aetna to work with AllState, Travelers or Progressive in this regard.
Now ask yourself, do you think I would be successful in asking for specific contacts from a vendor so that I can have a conversation above a reference check for their product? So, even getting federation going with those who have capability to federate is problematic. A typical engineer would not have this type of contact information and could only be gathered by sales people. Do you think asking someone who makes their pay based on selling would take the effort to unify people that wouldn't result in a sale?
If you ask how would one get a sales person engaged? The answer is for employee of Enterprise A to introduce the sales person to Enterprise B. This would allow enterprise A to not spend time educating business people in Enterprise B, but this still would at some level turn enterprise A into a lead generation mechanism for vendors. Is this the right answer?
While I haven't covered all the permutations, I think I wanted to share a sense as to why federation adoption is slow. SAML 1.0 was introduced ten years ago yet we still see few industry-wide federations. The only thing that will overcome this challenge is if we all in the identity community agree to change the conversation. We need to talk less now about interoperability and more about best practices around community formation.
The next blog entry will address other challenges...
| | View blog reactionsMany people are aware that one of my current activities is in figuring out how to bring federated identity technology to the property & casualty insurance vertical, specifically targeted at independent insurance agents. In order to provide a little context as to my approach, I figured I should start with an overview.
An independent insurance agent can do business with a variety of carriers ranging from Travelers, AIG, Geico, Liberty Mutual, Progressive, OneBeacon and so on. Each of these carriers will have their own policies related to how often a password should change, its complexity and how often a previously used one could be reused. An independent insurance agent could have business relationships with 30 carriers or 300 carriers depending upon its business focus.
So, one can quickly conclude that this business model brings lots of challenges to end users in managing their passwords. Now consider why it is important for it to be done properly as a consumer.
Consider your interaction with an insurance agent where you want to get a homeowners and auto insurance quote. The agent will of course want to know lots of personally identifiable information such as your drivers license to ensure you are a good driver, your social security number such that they can do a credit check and of course may desire your credit card as a method for paying for the policy.
This insurance agent will want to know how far you drive to and from work which means he also may have a strong sense as to when you aren't home. He may know about all the goodies in your house especially items that have high street value ranging from jewelry to furs.
So, let's say you have your trusty policy in hand and get into an auto accident where you smack your head bleed all over the dash. Their of course will be a claims file containing medical information. In summary, the insurance ecosystem has more information that consumers are otherwise blissfully ignorant about.
Most people are worried about healthcare data and leakage. It has always been my opinion that this matters less than insurance. Ask yourself, which would be worse, someone knowing that you have erectile dysfunction or as Paul Madsen would say, your wife learning about you insuring a car she didn't know about...
Let's start with the premise that the business controls all the funding for IT. While a business person can understand the challenges of having too many passwords and probably could calculate support costs associated with this worst practice, they probably couldn't articulate a vision that sounds anything like what federated identity solves for.
Taking this thought one step further, IT generally speaking follows traditional habits. If a business analyst were assigned to capture requirements around federation such that this feels like a traditional IT project and top-down driven, what would they capture? Do you think most business analysts have a clue as to how to capture business requirements around federated identity? Most business analysts at best are barely capable of capturing basic security requirements for applications they are familiar with.
So, does this get connected by enterprise architects? The answer is maybe, but ask yourself what evidence exists that says the vast majority of enterprise architects even have security (other than compliance) on their radar? Enterprise architects tend to travel is certain circles. When was the last time you went to any conference on enterprise architecture where federated identity was discussed?
So, we can conclude that top-down more often that not will be a fail, so let's look at it from another dimension. Since the independent agent would want each carrier to implement federation capability consistently, how would they organize a community around this? Are they properly equipped to even put pressure on carriers to ensure consistent implementation?
Another lens would say that carriers should network with each other. Ever heard of Elliot Spitzer who believes that these types of interactions are collusion-oriented? Even if Attorney Generals decided to not be an impediment, how would one person in enterprise A even know to find the right person in enterprise B? The person in enterprise A could do basic research and attempt to contact the business but understand that human nature says that most people will not forward things to others until they understand it themselves. We also concluded that federation is a challenge for business to understand. Does person in enterprise A spend his time on educating business customers in enterprise B? What CEO in their right mind would allow this to happen?
OK, so you are probably have concluded we haven't leveraged vendors to help us with this challenge. In order for a Microsoft, Oracle, Ping Identity, RSA, etc to assist with this, they first must understand what your business is. I went down this path myself and found that all of the vendors knew I worked for an insurance company but none of them could tell within their own CRM systems what kind of insurance company I work for. They couldn't distinguish between P&C, Life, Health, Re-insurance, etc which is important to the use-case.
In this model, Aetna may have merit in coming up with standards used in health insurance along with WellPoint, Cigna, UnitedHealthCare, etc but it wouldn't make sense for Aetna to work with AllState, Travelers or Progressive in this regard.
Now ask yourself, do you think I would be successful in asking for specific contacts from a vendor so that I can have a conversation above a reference check for their product? So, even getting federation going with those who have capability to federate is problematic. A typical engineer would not have this type of contact information and could only be gathered by sales people. Do you think asking someone who makes their pay based on selling would take the effort to unify people that wouldn't result in a sale?
If you ask how would one get a sales person engaged? The answer is for employee of Enterprise A to introduce the sales person to Enterprise B. This would allow enterprise A to not spend time educating business people in Enterprise B, but this still would at some level turn enterprise A into a lead generation mechanism for vendors. Is this the right answer?
While I haven't covered all the permutations, I think I wanted to share a sense as to why federation adoption is slow. SAML 1.0 was introduced ten years ago yet we still see few industry-wide federations. The only thing that will overcome this challenge is if we all in the identity community agree to change the conversation. We need to talk less now about interoperability and more about best practices around community formation.
The next blog entry will address other challenges...
