Radovan Semančík's Weblog

Recent discussions are about whether push or pull is the right model for future identity management. Unpractical standards are being revived. Everybody discussing the technology, the future, the visions. There is almost no discussion about the most difficult current problem of identity management: data.

There is (at least) one critical problem with implementation of single sign-on, identity federation, provisioning to the cloud and other fancy buzzwords. The problem is user database. It is not that difficult to deliver the information that someone should have access somewhere using whatever push, pull, standard or proprietary method - as long as you have that information. The reality is that enterprises does not have that information in a usable form. It is almost always distributed in several data stores, usually provided in incompatible formats, it is often inconsistent and sometimes even contradictory. And it is far from complete. Many provisioning cases are solved by non-algorithmic methods, e.g. manager or security officer deciding whether the request "looks valid enough" to be approved. The current situation is best described as semi-organized chaos.

How could anyone build an automated, Internet-scale, cloud-enabled and standards-based identity management mechanism on top of that? Hardly. Such project will most likely fail. But it will waste a lot of time and money before it fails.

The first step is to consolidate the data. Build a consistent user database, align policies, design business processes that can support 80% of cases with 20% of effort. It is naïve to expect that everything could be automated, therefore prepare for a reasonable amount of exceptions and human interactions from the very beginning. Single sign-on, identity federation, support for the cloud (whether push or pull) and even the standards will not provide any considerable help in that. It is mostly manual work of security staff, business people and engineers that is needed.

What can help is a well-designed and well-deployed provisioning system. In contrary to the popular beliefs the provisioning system is not really about provisioning. Yes, provisioning is a important part of the system, but other aspects are in fact much more important. Provisioning system can take data from several sources, covert them to a common format and merge them. Therefore it can create a unified database. Provisioning system can compare data among several system, correlating them, therefore detecting the inconsistencies. Provisioning system supports workflow and human interaction to clean up the data and supplement missing information. Both during initial migration and (most importantly) during the day-to-day operation.

Reasonable identity consolidation project including a decent provisioning system is a necessary pre-requisite for any other identity-related activity. It is a shame that engineers forget the Garbage In, Garbage Out phrase that was popular few decades ago. If the data are bad, any system built on top of such data can only be worse.

Only a small pieces remainded from the Sun Identity Manager (IDM) after Oracle swallowed Sun. One of the biggest pieces is Identity Connectors Framework. I guess it was an attempt to replace Sun IDM adapters - a part of the system that was asking for re-engineering since the times of Waveset back in 2003. Yet, Identity Connectors are not really an ideal replacement.

The goal of Identity Connector is to connect to a remote system. It should provide list of accounts, groups, roles or any other objects that are interesting from identity management point of view. It should be also able to manage such objects - to create, modify and delete them. Identity Connector Framework provides typical API/SPI abstraction to plug in connectors for various systems. It even seems to isolate the individual connectors to a separate classloaders. It allows to run connector on a remote host. So far everything is pretty much OK.

It is naïve to expect that all target system will use the same structure for accounts and groups and other objects. Therefore the connector provides a schema that describes how such objects are structured by the resource. That is major improvement over Sun adapters and it also should be a major competitive advantage of Identity Connectors. Only if it was designed a bit more carefully. First of all, it looks like the intent was for the schema to use native naming of object classes and attributes from the target system. E.g. complete LDAP schema with native object class names and attributes is visible using the connector. On the other hand, the framework provides pre-defined and fixed object class names __ACCOUNT__ and __GROUP__ and even predefined attribute names for __NAME__ and few others. I cannot understand this dichotomy: on one hand exposing the full native schema, on the other to hide it behind a cumbersome abstraction. This duality complicates the design of any system that is trying to use the connectors correctly. E.g. both __ACCOUNT__ and inetOrgPerson object classes are exposed by the LDAP identity connector and they are the same. Which one should be used? The root cause of this problem seems to go a bit deeper: the connector does not have clearly defined responsibilities. Should the connector only provide access to the object on target resource (i.e. be a simple protocol adapter)? If yes then there is no need for special __ACCOUNT__ and __GROUP__ object classes. Or should the connector also map the target system schema and provisioning system schema? For that it does not have sufficient features (see below). It looks like the connector goes somewhere in between, trying - and failing - to address both problems.

Yet another feature that I would expect from a "next generation" identity connector is to handle object references or membership. It means that provisioning system should be able to discover that there are two grouping mechanisms for LDAP and one (proprietary) mechanism for roles. That will allow provisioning system to provide much better GUI and business logic support out of the box. Yet, identity connectors do not provide such feature. The unix group attributes are of type string. There is no information in the schema that would suggest that a __NAME__ (or Uid?) of an object from the __GROUP__ object class belongs there. There is even no way how to know that there is more than one grouping mechanism (that is pretty common in LDAP and in many custom systems). How can provisioning system handle that? Either it cannot and leave that to business logic (which make deployment hard) or it can build an adaptation layer on top of connector. Abstraction on top of abstraction. Insane.

Overall it looks like the folks at Sun have chosen the wrong way. Identity Connectors are not that much of an improvement over older adapters that I would expect. It looks like the responsibilities should have been defined much better. And I would suggest that schema annotation is much preferable over schema transformation in this case. The Identity Connectors Framework needs a radical improvement even before they have gained any serious acceptance.

The punch line is that Oracle is planning to use this very mis-designed framework to improve their Oracle Identity Manager.

Management summary: The Sun is setting. Some of its fortune can hopefully be saved, some of it will be probably lost. Attempt to replace practical mess with unusable dead horse seems to be futile. But shamans still favors it.

Technological company Sun Microsystems is being swallowed by Oracle Acquisitions. Sun had many interesting products in the portfolio. Being a technological company, Sun has failed to capitalize most of them. I've heard that Sun will never miss an opportunity to miss an opportunity. That describes the Sun's business strategy quite well. Nevertheless, Sun had some relatively good technologies. Software technologies. Even some successful products. Now it seems to be quite clear that most of them will be killed under Oracle Acquisitions rule. One company is bold enough to try to save some of the Sun's portfolio. Fortunately Sun has made some of its products open source, so there is some chance they can be saved. This can be an interesting precedent. Can open source strategy give customers better continuity than over-priced commercial support agreements? I wonder ...

Our company was a Sun partner and most of our team worked with Sun technologies since the dawn of the Internet in our post-communist country. Last 6 years we have specialized in identity management. Sun Identity Manager (aka Waveset Lighthouse) was quite a successful product. It has surprisingly high market share. However it was quite a mess. It was really wild mix of ingenious ideas, bad decisions, layers of duct tape and engineering dead ends. But it was understandable, extremely flexible and has the right set of development tools. And it worked. Mostly. The decision of Oracle Acquisitions to kill Sun's products was quite a hit. It hit us as badly as it hit our customers. Oracle is proposing its own product as an alternative. But IDM solutions are usually heavily customized. Anyone claiming that migration to a competitive technology will be easy is speaking from ignorance at the very least. The migration means reimplementation. All the effort and all the costs "invested" again. Our customers were left in the void by the decision of Oracle, therefore we were "motivated" to look around for alternative solutions.

The natural choice was Oracle Identity Manager (OIM), the thing that Oracle acquired with Thor few years ago. However, the product is unusable. That's how it is, plain and simple. The product itself may not be bad, but it is extremely difficult to customize and use. In fact it may be easier to implement IDM solution from the ground up than to customize OIM. My personal estimation is that IDM project with OIM will require at least three times more effort than similar projects with Sun IDM. OIM has really minimalistic tools, terrible debugging and diagnostics mechanisms, no build system, minimum deployment support infrastructure. Engineering nightmare. As I was staring at the monitor in disbelief and trying hard to figure out how that Thor beast works, an old Dakota tribe saying came to my mind: When you discover you are riding a dead horse, the best strategy is to dismount. Therefore I've dismounted.

Now I can understand why OIM has almost no deployments in our region. However, I do not understand why analysts put OIM in their magic quadrants. OIM surely provides lots of cool features in the marketing slideware presentations. But once it gets to real installations, it takes so much effort to implement simple things that the effort to implement something moderately complex will be counted in man-decades, if not man-centuries. Is that the "ability to execute"? A friend speculated that analysts never install. And after the experience with OIM I'm quite inclined to believe that. One way or another, my confidence in the analyst's product assessments suffered considerably.

The experience with OIM, however bad it was, provided a valuable lesson: usability, usability, usability. The product may be based on unique ideas, innovative technology, it may be a work of real genius - however all of that is vain if the product cannot be understood and efficiently used.

The Web and especially OpenID has yet to learn important lesson: nothing is permanent. Will Norris mentions it in his post. To make his long story short, the problem is that OpenID relies on DNS and DNS names can be reassigned. With change of control of DNS name the control of associated OpenID identifier is changed as well. Therefore a user may be required to pay for a domain that he does not want any longer just to avoid losing control over the OpenID identifier. The root of the problem is that DNS is not really an identification mechanism, but rather an addressing mechanism. OpenID design does not account for that.

The purpose of address is to locate an object, therefore it contains information about object's location - directly or indirectly. Address must change if the location of the object changes. DNS is using a level of indirection to reduce the number of changes needed if object location changes, but it does not reduce them to zero. You may be forced to pay for a domain forever if you want to make DNS name a permanent identifier - assuming you can do that at all. For example the rules for sk top-level domain will force you to yield your domain in case someone registers a trademark that is the same as your existing domain name. Therefore making DNS name persistent may be quite costly. DNS domain is an address. Get over it.

The purpose of identifier is to distinguish the object from other similar objects. Well-designed identifiers does not need to change. The identifier may identify an object that does not exist any longer, but it should never identify a different object. Think of ANS.1 OIDs, ISBNs or similar identifiers. For identifiers to be efficient their assignment should be very cheap and maintenance must be extremely cheap or entirely free.

It is not wrong per se to use address in your system. But it is a mistake to use an address and assume that it has properties of identifier. It is a failure to assume that address will not change - almost as serious a mistake as assumption that identifier can always be resolved.

Technorati Tags: identity OpenID identifier address

Kim Cameron recently posted a paper "Proposal for a Common Identity Framework: A User-Centric Identity Metasystem". Although this paper is hard to read at places, it brings up some interesting points. It somehow formalizes the "Identity Metasystem" in form of a set of abstract services, which I understand as (possibly unconscious) attempt at creating a abstract architectural layer for identity services, one of the shearing layers in software architecture.

The paper suffers from inconsistent terminology and its use through the paper. If frequently fails to distinguish cyberspace entities and realspace entities. It also seems to assume a binary view of trust: something is either "in doubt" (in claims) or becomes a "fact". I consider this binary view to be one of the worst fallacies of most current identity architectures and systems.

However I believe that the worst drawback of the proposed architecture is that it does not reflect one of the most important requirement for Internet-scale distributed systems: the requirement to support positive Network Effect. If the network node can communicate with each other directly, the value of the network is proportional to the square of the number of nodes. However, if communication is limited to channels, the value of the network is significantly limited by the number of channels. The value of such channelized network grows much slower. In the identity space you can see an example of this in the PKI for qualified digital signatures. This PKI is being constructed for almost 10 years, received substantial investments both for research and implementation, it was frequently stated that there is a need for such a mechanism. And still the technology acceptance is very low. May the limitation to channel identification through the accredited certificate authority channels be one of the reasons for PKI failure?

The paper proposes or assumes similar channelization of the Identity Metasystem: the contractual agreements between claims providers. I don't believe it is feasible to consider contractual agreements between network nodes in Internet-scale systems. There are just too many connections, combinations of interactions. How many claims providers there could be on the Internet? 10? That's clear monopolization. 100? That's approximately one per country. I think that there will be much more of them. Probably one per an organization. That means millions. And that means millions of millions of contractual agreements. That's clearly unfeasible. There would need to be trusted third parties that will "bridge" gaps between organizational claims providers. And there we are back in the PKI world which haven't demonstrated any substantial success on the Internet during a decade of well-funded efforts.

I think that the primary problem is in the binary view of the "trust". The information in the cyberspace cannot be considered to be "facts", but rather an opinion of its author. No information is absolutely reliable and all the information (at least in cyberspace) is subjective. Therefore there may not be a strict need for a contract between parties, but rather a method of a proper risk management and information reliability evaluation. Any "identity" system needs to be firmly based on a "trust" infrastructure between nodes, between resources, cyberspace entities. And I don't think that a "trust" infrastructure based on a binary view would be feasible on the Internet scale.

Technorati Tags: identity metasystem trust PKI security

Users do not authenticate themselves to web applications. Users pass their password to their workstation (or any terminal device) that will pass it to the browser which will in turn pass it to the web application. The application does not interact with the user, it interacts with a browser software installed on a machine that is (maybe) used by human being. I have described that long ago in a persona model. Now Fulup Ar Foll mentions similar thing in this quite interesting interview. That's good. At least one more person is having the same idea. Maybe we are getting somewhere.

You may ask what is the difference? Authenticating user or user's computer or whatever? The user cannot be sure that his computer or mobile device is operating as expected. And well, let's admit that many people have no idea what that damed machine is doing. It is easy to make a mistake and send your password to a wrong site (phishing). It is difficult to defend against viruses. And we are damned lucky that vast majority of the viruses are pretty harmless things. Computer or mobile device can be stolen, ale your persona may be stolen as well. Just admit it, the device you are using to interact with the cyberspace is just not secure.

More and more important services are getting on-line. They assume that the entity that is providing credentials is really a human. But it may not be the case. It is much safer to think in terms of "digital persona" than "living person" when it comes to the design of authentication systems.

And that also means that the entire field that proudly calls itself "user-centric identity" is in fact a bunch of machine-centric solution.

During last few months there were quite simple but very effective phishing attempts at twitter, deviantART and maybe also other social sites. The phishers spoofed login page of twitter (or deviantART). They sent out a catchy messages along the lines of "funny blog about you" or "I have seen your photos on this blog". These messages contained link to the spoofed login page that phished user passwords. Phished credentials were used to spread the message further, creating an avalanche effect.

This approach was efficient because the messages were apparently coming from trusted friends. Why would a good of friend of mine send me to a phishing page? Because he was phished just a minute before! Simple, but efficient. My estimate is that a significant portion of users that were on-line fell in this trap. I was on-line on deviantART when this happened. As far as I know nobody of the people that I watch detected that the login page was spoofed. They have only detected the consequences: that someone is sending out strange messages using their account.

I have immediately noticed that the login page was spoofed. The spoofed page was slightly different than the normal login page. But the primary reason that I was alerted was that the page was out of context. I should be seeing a blog that stole my photos, not a login page. I haven't logged out and the session should not expire in such a short time. An immediate look at the URL bar confirmed my suspicion.

This specific phishing attempt was not very sophisticated. But if the phisher tries a more subtle tactics next time, I may become a victim as well. Such a tactic will probably display a login page in the correct context, where it is expected. Even the most cautious users may automatically enter the credentials without any suspicion (you just cannot watch URL bar all the time). Now it is quite difficult to construct a phishing message that would direct you to a login page in the right context. The correct context for entering a password is at the start of interaction with the site. But the world is changing ...

Using OAuth it is usual to enter your username and password almost any time during the interaction with a site. OAuth will normally redirect user to your trusted site that stores his data - to request an authorization to use the data. But that usually results in asking user to log in. It may be quite easy for a phisher to simulate that flow and to spoof the login page of the legitimate page. OAuth in fact trains users how to get phished easily by making the normal use case similar to the phishing case.

This problem is amplified when OAuth is combined with OpenID. It is not a big deal if a twitter password gets phished. But if a key to the OpenID kingdom is phished, that may be entirely different story. OAuth-OpenID combination is increasing the exposed surface as well as impact: there are more places that user may be phished and the phished credentials are more valuable.

I can understand that neither OAuth nor OpenID created the primary problem. But the use of OAuth and OpenID is amplifying existing problems. Therefore instead of increasing the privacy and security of users the use of these mechanisms may if fact have exactly the opposite effect.

There is a reputation discussion all over the blogsphere. The question is simple: What attributes should be influenced by reputation and what should not?

The answer is simple as well: The question just does not make sense. I will try to explain that, but it needs a bit of philosophical background.

Information is subjective. If I say I'm dependable, what I'm really doing is expressing my opinion about my dependability. When my customers say that I'm dependable, they are expressing their opinion about me. When my dear competition say it's not all that good about me, they are expressing their opinion. It is quite obvious that some abstract concept such as dependability cannot be objectively measured. And therefore it should be somehow (read: magically) determined by combining several values from several sources. That mechanism is now part of the "reputation" buzzword.

But what happens if I say I'm 195cm tall? My height is an objective fact. That should be somehow different from the abstract concept of dependability, shouldn't it? No, it shouldn't. If I say I'm 195cm tall I'm expressing my opinion about my height. How can you make sure that information is true? You can send someone here to measure my height, and he will get the same number. But if he publishes that on the Internet, it's just his opinion on my height. Both of us can lie and I may in fact be only 150cm tall. Or we can both use broken tape measure. Who knows? Who can be sure?

Any information is only as good as is the source it comes from. It does not matter if it is information about dependability or height. There may be objective facts, but information is always subjective. Even if it tells about objective facts.

Therefore all that havoc about reputation just doesn't make sense. The question is not "What attributes should be influenced by reputation?" The question is "How we are going to determine trustworthiness of any information?" Whether it is dependability or height, the mechanism should be the same.

Identity is mainstream.

Lot of ill-advised identity technologies are roaming around. Technologies that does not really solve anything and are just technology toys. Or technologies that solve just a routing of revenue stream, not the real problems of users. I wonder if evolution can handle that and how fast will these technological abominations die. There is couple of corpses already. And more will (hopefully) follow. I hope that evolution can eventually balance this.

Lots of self-established identity experts are appearing. People that think that identity is all about technology. Thinking that reading few identity stories in popular press is enough to become an expert. Believing that if they would follow the hype they will surely get the best of that identity thing, whatever that may be. They obviously does not have a bit of viable experience in the area. People that re-invent the invented just because few hours in the library can be saved by few months in the laboratory. People that implement useless work-around mechanisms instead of focusing on the core of the problem. People that deploy technology just because it comes in the box that has the right colors on it. I wonder if evolution can handle this as well. But I'm afraid it cannot. These guys are usually well disguised as serious engineers. We know all too well that camouflage is usually a good survival strategy.

Business as usual. Identity definitely is mainstream now. All the obvious symptoms are there.

I see that over and over again. Recently it has appeared here. So let's make it clear:

Identity is NOT about identification

Identity is all about sharing the data. Identifiers may or may not be part of that sharing. Identifiers are just ordinary piece of information with a purpose to link objects. It not special to "identity" in any way. If you see "identity" just as a identification you are missing the crucial point.

I believe that the "user-centric identity", federation, SOA-based "identity" mechanisms, social web and VRM are all the same. Not similar, but same. They all solve the problems of controlled data-sharing somehow related to people. Data sharing, that's what it is. And unless all the "identity" and VRM and "social" folks understand that they are in the same business, we will not get anywhere.

I like it how everybody pretends that they know what "identity" means ... while nobody really knows. There is no viable definition what "identity" means when it comes to the computers.

What does Internet Single Sign-On systems really solve? Is all this upset (caused especially by OpenID) good for anything? Let's summarize the benefits and drawbacks:

• Benefit: I do not need to remember many passwords. I just long in once and then any site I'll visit will recognize me.
• Drawback: My OpenID provider may not be recognized by all relying parties. Even if the situation now is in the naive state that everybody "trusts" everybody, it cannot be sustained. The providers will differentiate. Therefore I will need to maintain several accounts with several identity providers anyway.
• Benefit: Still better to have several accounts than thousands of them.
• Drawback: Even if I have SSO, I still need to click on "log me in using OpenID" link on a target site. Therefore the user experience is still the same as having a browser remember the password for me. And the browser still needs to remember your OpenID URL to have it "one click" experience.
• Improvement: This can be improved by some kind of identity provider auto-discovery and automatically log the user in. However, there are dangers ...
• Drawback: If a website can make my browser to automatically log me in, the same thing can be done by a script running in my browser. The impact of cross-site scripting exploits will get worse. Much worse. If my back would accept OpenID-based SSO with an option for automatic login, clever attacker can take all my money and I will not even notice that it happened. Phishing may get to the next level ... maybe we will get "phishing trawlers"?
• Benefit: Some SSO systems may transfer attributes from identity provider to relying party. That may be useful. I will not need to always make sure that my billing address that is remembered by an electronic shop is correct. I will not need to always look up my ZIP number (as I cannot remember it). That can be a real benefit.

My assessment is that Web SSO systems that just do SSO are useless. Absolutely useless. Dangerous even. I think that for this stuff to work reliably and securely the browser needs to understand the security protocols. The browser needs to present appropriate user interface, such interface that cannot be feinted by a script. And most of all: the SSO itself is a next-to-none benefit for users. Add attributes to that and it may gain some attractiveness.

Do not take this as an endorsement of CardSpace. While CardSpace may solve some of the above issues, it has its own set of problems. But I will keep that for later.

The European Court of Human Rights has ordered the Finnish government to pay out €34,000 because it failed to protect a citizen's personal data. One data protection expert said that the case creates a vital link between data security and human rights.

The Court made its ruling based on Article 8 of the European Convention on Human Rights, which guarantees every citizen the right to a private life. It said that it was uncontested that the confidentiality of medical records is a vital component of a private life.

The Court ruled that public bodies and governments will fall foul of that Convention if they fail to keep data private that should be kept private.

The woman in the case did not have to show a wilful publishing or release of data, it said. A failure to keep it secure was enough to breach the Convention.

(Source out-law.com via Emergent Chaos)

I wonder how is this going to change the economics of government data protection. I hope that this ruling can achieve what a horde of legislation, government-initiatives-in-good-faith and other (more "commercially-oriented") government initiatives failed to achieve.

And if my hopes will not be fulfilled, at least I know to whom should I appeal in case my privacy will be invaded. I'm glad that I live in Europe.

Not that long ago W3C TAG recommended to vote againts XRI Syntax and XRI Resolution specifications to become OASIS standards. The reason given by the W3C TAG was ridiculous:

We are not satisfied that XRIs provide functionality not readily available from http: URIs. Accordingly the TAG recommends against taking the XRI specifications forward, or supporting the use of XRIs as identifiers in other specifications.

Anyone with some common sense and the knowledge of both Web Architecture and XRI specs can clearly see that XRI specifications are as immature as Web Architecture is broken. Childish flamewars like this will not bring any good for any of them. Paul Madsen summarized that in his usual brilliant style.

While the follow-up explanation from W3C member Dave Orchard raises few good points, some thoughts are quite extreme:

Protocol independence appears to be a bug on the web, not a feature.

Statements like this one must alert any experienced software architect. Has the world (wide web) really went nuts?

I've realized I have plenty of these already. So one more does not really matter. And this one is almost as useless as my twitter, orkut, facebook and myspace accounts. Almost.

For all the fans of Buzzword 2.0

Recent gossip has it that HP and BMC are leaving the Identity Management arena. Interesting. It doesn't look like there is a business decline in the Identity Management segment. Rather it looks like a slow continual growth (disturbed only the the Identity Superheros that claim to solve all the problems). Then why are these two companies pulling back?

I can only speculate here. And my speculation is that the reasons may be related to the hidden complexity of Identity Management deployments. It is trivial to Identity Management software and do some basic configuration. But that's only the beginning of the real Enterprise Identity Management project. The real fun follows after that: using organizational structure, aligning the processes, building up roles, ...

The Identity Management project is a multi-year venture. It is not only the deployment of software. It is rather an architectural change. A paradigm shift. Whatever you slice the project to fit into a year's budget, you cannot change the very nature of it.

That may be the reason why usual quick-turnaround sell-install-invoice integration-wannabe project approaches fail. The IdM project executed in the proper way is not really a high-profit business opportunity for software vendors. Unless they sell expensive professional services along with the solution, which usually makes the cost unjustifiable and the results inconclusive. The reason is in motivation. Vendor's motivation is to sell the product, not to solve customer's problem. My opinion is that vendors by themselves cannot solve practical problems of Identity Management.

My solution? Find a proper partner for the project. Either a big consultation company or a small specialized company (Note: I have vested interest in this option). The big company may already know a lot about your system and can approach the problem from several angles. Therefore it can solve a lot of related problems, both technical and business. They have the manpower. But the cost is invariably high (or the solution invariably poor). Small specialized company will focus on a small set of problems, usually providing good results in a specific area. But the scope of the small company's solution is always limited.

... I wonder what will be the approach of IBM, Oracle, Sun and other IdM vendors. Will they make the same mistake?