Radovan Semančík's Weblog

It is time to publicly announce a project that I was working on recently. It is an open-source identity management system named midPoint. It is based on the OpenIDM version 1 code developed by the our part of the team. MidPoint aims to be a usable, pragmatic IDM product. We have based it on many years of experience deploying other IDM products. We have learned from what worked and what have been failing during real deployments. The bad thing is that too many things failed - and that's something we want to improve with midPoint.

MidPoint is a user provisioning tool. It can do basic provisioning as well as provisioning driven be expressions. It is using Identity Connector Framework (ICF) to connect to other systems. It has a live synchronization capability (similar to Sun ActiveSync) and other synchronization methods are under development. There is a basic RBAC support that is continually improving. Lot of time and effort was invested into diagnostics and support for deployment such as good error reporting and logging. We know where are the pain points of IDM deployments and we are working hard to improve what we can.

MidPoint version 1.9 was released few days ago. It is a third version developed under the Evolveum brand name. This version is worth checking out as a preview of the final product that is planned as version 2.0 for early next year.

Technorati Tags: identity management IDM provisioning

The OpenIDM project is getting up to speed pretty fast. We have done a lot of work recently, but there is even more work to do. Although OpenIDM is led by ForgeRock it is an open-source project as it should be. The project is open to the community from the very beginning, but now it is a time to encourage broader community to participate.

The OpenIDM Design Summit 2011 is a place for a design discussions, place to ask questions and get answers. It a place to participate. I will be glad to see all of you in Oslo in few weeks (January 26-27).

A giant leap have happened today, even that it may look like a small step from the outside. OpenIDM Snapshot 1.5 was released today. OpenIDM is an open-source provisioning system. The source code was fully available from the very beginning, but this is the first real release of the product, although it is only considered a snapshot, a preview release. I'm very proud to have a chance to participate on that.

OpenIDM does not do much if seen from the outside. It does very basic provisioning and few other minor things. The real goodness is under the hood. OpenIDM is based on component architecture. It is in fact just a bunch of components that can be combined in multiple ways. The components can be modified, inserted or replaced with custom solutions. OpenIDM is based on ESB/JBI principles, therefore the components may take a various forms, including Java, BPEL, XSLT and others. Yes, BPEL is a native part of OpenIDM from the very beginning rather than being some kind of afterthought. The inter-component interfaces are defined using WSDL, so the implementation language does not matter that much. And it is "contract-first" WSDL, manually written and carefully designed. It is not generated by some kind of tool that almost works. OpenIDM takes the architecture seriously. Take a look yourself.

OpenIDM has Identity Connector Framework as a workhorse. So even though OpenIDM is a new thing, there is already a decent set of connectors that can be used with it. The tooling is provided by Netbeans SOA plugins now. There's composite application editor, graphical BPEL editor and debugger. And much more than that - a complete environment that a serious developer would expect. And honestly - IDM projects are heavily customized, good development tools are really critical in IDM field.

I believe that OpenIDM is starting a new generation of IDM systems. That's definitely one of the project goals. We have made a first leap today. I would like to thank a lot everybody that was a part of it. And I'm already looking forward to the next steps. It will happen ... soon!

These are just my personal opinions as an engineer. It is not an official statement of ForgeRock, nLight or any other entity except myself.

Technorati Tags: identity enterprise IDM provisioning ESB OpenIDM

Everybody knows RBAC, the Role-Based Access Control. The principle is simple, the theory behind it seems to be sound and it is very popular. The problem is that is does not scale. RBAC is fine for few tens of roles. But as the number of connected systems grow, the number of roles grows as well. Organization with thousand employees can easily end up with few of thousands of roles. The difficult problem of managing thousand employees will be transformed to even more difficult problem of managing few thousands of roles.

The reasons are quite understandable but they are far from being obvious:

• Cartesian product: Let's have roles for bank teller, supervisor and branch director. Let's operate in London, Berlin and Bratislava. We need a role for "teller in London", "teller in Berlin", ... 9 roles total. The number of roles grows very quickly.
• Atomization: This can be sometimes avoided by decomposing roles to re-usable re-combinable units. Combine them to a "higher-order" roles using role hierarchy. This gives us 6 roles instead of 9. Unless the teller shares part of the access rights with janitor. Then we need "basic branch office access" role, "teller's IT access" role and a "teller" role that combines these two. Now we have 8 roles. The number of roles still grows quite quickly.
• Uniqueness: Many employees have one-of-a-kind set of access rights. Any attempt to fit them into the roles will inevitably result in a number of roles that is equal or greater than the number of such employees. This is quite pointless.

Static RBAC model usually cannot be used to efficiently handle role explosion. There are some solutions, but none of it is a panacea:

• ABAC - Attribute-Based Access Control. This seems to be a new buzzword. The principle is that instead of having roles there is a expression that computes access rights. The expression takes user attributes as parameters. It seems to be very flexible. But it is a new concept and has yet to be proven. Also, it replaces formal structure of roles with logic. That smells of programming instead of configuration. ABAC may solve the problem of role management, but does it also solve the generic problem of policy complexity and management?
• RBAC, but forget about least privilege. Create "bigger" roles than what would the principle of least privilege dictate. Roles that allow much more than they should. This will improve role re-use and keep the number of roles manageable. It is less secure, but may be good for some environments.
• Spice up roles with some logic. That usually means adding rules to make roles more generic without sacrificing security. E.g. instead of creating "teller in London" create a parametric role "teller" that takes locality from user profile as a parameter and computes the path to the home directory. This is somewhere between ABAC and static RBAC. It has good features from both approaches and seems to be the most popular choice for provisioning systems. But does it really solves the problems? Nobody seems to know for sure.
• Manage the chaos. Let user's request access rights, let others to approve it. The obvious problem is how to revoke the unneeded rights. There needs to be yet another process to review and revoke them, usually called attestation. It is a good for CYA strategy, as there is always someone who have approved what he shouldn't. But is it really secure? The approvals are often done by "I just look at it and if it seems OK I approve". Especially if someone has to approve hundreds of requests each day.

Practical enterprise IDM solution will most likely need all of these mechanisms, not just one. And especially a good, experienced team of people using these mechanism. Because every IDM deployment is different and one size does not fits all.

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.