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

Thoughts on SPML 3.0

Much of the discussion around identity provisioning is centered on employees where the authoritative source of data is usually an HR system. As the conversation moves away from the employee-demographic to business partners, several additional things need to be considered. I am glad to see that SPML is not on life support and that the identity community is committed to improving the OASIS SPML specification. I figured I would share a few thoughts on what I would like to see SPML 3.0 address...




Metadata
Currently, the SPML specification describes the operations that can occur against a given user schema but does not define either a model for any particular user nor even provides a mechanism to discover supported models. If companies wanted to expose their SPML services to their business partners, they would need to first manually define what the user model looks like and then duplicate the information within each implementation. This approach is fragile and error-proven.

The ability for one identity management tool to understand the user model that another identity management tool is best supported by developing interoperable metadata exchange capabilities. At some level, the SAML specification supports this construct and it would be good if SPML supported something similar.

Virtualization
Their is an implied coupling between SPML operations and the underlying data store. For example, if you wanted to store a person and an organization, you would need to potentially invoke this as two separate operations. More importantly, one of the general principles of a service-oriented architecture is to avoid coupling, it would be bad form for you to describe your internal data structure externally and therefore a virtualization layer is needed.

Many enterprises will be coerced into thinking that virtualization is solely a construct that separate the SPML gateway from its underlying store. Others could argue that virtualization in this regard really shouldn't be a separate product but something baked into each implementation especially to aid in describing the metadata requirements. Either way, the need for provisioning to operate supporting coarse-grained constructs that aren't one-to-one with the underlying implementation is a key consideration.

Entitlements
Imagine a scenario where salesforce.com exposes a SPML gateway to allow its clients to support provisioning and de-provisioning activities. This begs several questions related to entitlements such as can Client A provision an account that allows access to Client B's data? We all know the contractual answer, but in terms of how this is enforced within current SPML solutions is all over the place. Anytime, you need to support multitenancy constructs this issue is going to raise its head.

One can think about whether SPML implementations support industry specifications such as xACML but that is an oversimplification. Again, since SPML only defines the operations but doesn't define a common way to even understand who is making the request nor having any understanding of the target resource, an entitlements model is left up to the discretion of the implementer and may introduce additional security risks.

Minimally, it would be great if products defined the right extension points such that if an end-customer wanted to do something other than deferring to an XACML-based they could pull out a trusty SDK an implement a few nterfaces in order to make this happen.

Attestation
The requirement for an organization to provide attestation capabilities for whomever accesses their IT ecosystem is at the center of many organizational SoX controls. While enterprises can be enterprisey in their thinking and insular in their focus, shouldn't they also be thinking about how their business partners attest to access to their systems as well? Within an IT ecosystem, your systems may not only be under SoX scope for you but also your business partners as well and having the right interfaces to support attestation in a federated manner is becoming increasingly important.

Attestation standards usually specify standards of reporting. Within a federated provisioning model, this include exposing statistics on various provisioning workflows that include success/failure rates filtered for a given partner/call. It may also define obligations analogous to how XACML defines this notion where certain interactions with partners or transaction types may have additional logging/auditing/alerting requirements around them. For example, if I work for a major Wall Street Bank and I need access to a trading platform, one may want to define a different level of auditing if I am requesting access to a foreign currency trading platform than other levels of access since the risk profile is different.

Each business will have their own take on what needs to be audited but we need a general way to record the obligations of different parties in a federated provisioning scenario. This all should be driven by standards.

Static Analysis Worst Practices

We have been using static analysis for the last couple of years and I think I have uncovered a few worst practices that I wanted to share in hopes that others may avoid the mistakes we have made...



Many of the static analysis tools, whether Fortify Software, Ounce Labs, Coverity or others tend to be bought under the misguided belief that they automate the code review process. Reality states that these tools are great in terms of aiding software security professionals in finding defects, they aren't substitutes.

One of the biggest challenges in all of these tools is the amount of defects found by them. It takes human judgment in order to understand how bad a particular application may be in terms of its security posture above and beyond the metrics it produces. For example, the application with the highest amount of findings is actually pretty good in terms of its security posture and the application that has the least amount of findings is the one I would recommend a wholesale rewrite.

More importantly, the metrics produced by static analysis tools in terms of their dashboard do not even roughly correlate to what IT executives need in order to make decisions. For example, a security professional will want to make a decision based on various risk rating criteria ranging from difficulty of discovery and the skill required to exploit and these tools simply provide no visibility in this regard.

Security professionals tend to not just look at a one-off instance of a particular scan but may also study the longer term trends of an application. Think about what happens when Microsoft releases a patch for an exploit. They may want to go "backwards" and figure out what prior releases the exploit can take advantage of. The notion of backward-chaining and inferencing simply isn't built into most products.

Are you familiar with the concept of a buildforge where the goal is to automate how software is built in order to guarantee repeatable outcome? Many of the static analysis tools assume a developer is driving and not part of a larger process. As an agilist, I am a savage believer in the notion of frequent and automated software builds and static analysis puts a manual step into the mix.

How many dashboards does an enterprise need? Should I have a separate dashboard for static analysis tools? Should the findings be merged with those acquired from web vulnerability scanners? Should this information be rolled up into GRC tools? Should this information be incorporated into EA tools such as Troux and Alfabet such that an enterprise can do strategic planning on its portfolio where security is just one aspect of an application?

We need to have honest conversations on the strengths and limitations of static analysis. Otherwise it will result in another oversold enterprise tool and security posture of the enterprise will suffer...