Virtual Desktop Infrastructures (VDIs) are hype. But are they really a strategic element of IT? Or are they just a deployment option? I think that the answer is influenced by two major aspects:

• Time and the maturity of Desktop Virtualization
• The functional breadth of VDIs

With respect to the first aspect, VDIs today are more sort of a more expensive, more complex alternative to Terminal Services. Less users per server, the same (sometimes a little bit more advanced) protocol for remote desktop access, very limited capabilities to run the VMs locally on a hypervisor – VDIs aren’t really mature yet. However that will change. We will see more deployment options, improved management capabilities, some improvements regarding performance (however, VDIs will always be expensive in terms of compute power at the server), and so on. And especially with different local deployment options (streamed, synchronized), the need for remote desktop protocols will disappear, mobile users will be fully supported and less servers will be required – without giving up advantages like the (relative) independence from hardware and some centralized management aspects (which are, however, not that different from other deployment approaches).

The other aspect is about management. Is isn’t sufficient to integrate the management of server and desktop virtualization – and even adding storage virtualization management to that is not enough. Application virtualization has to be integrated as well. But even then we have some lack of capabilities:

• There will most likely be other types of desktops for a pretty long time – the more specialized ones for “power users” and “knowledge workers”, for specific user groups like engineers or stock brokers, and so on. It is not only about the 50% or 80% of desktops which fall into few standardized categories. The main issue are always the remaining 20% or 50% of not-that-standardized desktops. And they have to be managed centrally as well.
• That requires configuration management and software deployment beyond building few standard images. Image management in reality is far more complex than just having few standard images. And not every application can be virtualized. Beyond that, we need several other elements which typically are found in Client Lifecycle Management today: Think about inventories and License Management. With other words: You will either need Client Lifecycle Management (CLI) or VDIs have to fully integrate that in the future.

In the future, a more complete VDI stack with full CLI support and optimized support for local deployments and mobile users might become the standard – even for older operating systems and non-Windows platforms. For the meantime, it is probably the better strategy to understand VDIs as one deployment option amongst other and to integrate all these deployment options under centralized management system. At least it is a good idea to be realistic about VDIs and not too enthusiastic.

So I’m a believer in VDIs – but I’m a sceptic regarding their short-term value for most use cases. What is your opinion on this?

LDAP (Lightweight Directory Access Protocol) is well established. It is the foundation for today’s Directory Services, which support LDAP as a protocol and which usually build their data structure on the associated LDAP schema. There are many interfaces for developers to use LDAP, from the LDAP C API to high-level interfaces for many programming environments.

Even while LDAP is well established, it is somewhat limited. There are several restrictions – two important ones are:

• The structure of LDAP is (more or less) hierarchical. There is one basic structure for containers – and linking leaf objects (think about the association of users and groups) is somewhat limited. That structure is a heritage of X.500, from which LDAP is derived – with LDAP originally being the lightweight version of the DAP (Directory Access Protocol) protocol. X.500 was constructed by telcos for telcos, e.g. with respect to their specific needs of structuring information. However anyone who ever has thought about structuring Novell’s eDirectory or Microsoft’s Active Directory knows that there is frequently more than one hierarchy, for example the location and the organizational structure. The strict hierarchy of LDAP is an inhibitor for several use cases.
• LDAP is still focused on the specific, single directory. It doesn’t address the need of storing parts of the information in fundamentally different stores. But the same piece of information might be found locally on a notebook, in a network directory like Active Directory, in a corporate directory and so on. How to deal with that? How to use the same information across multiple systems, exchange it, associate usage policies, and so on? That is out-of-scope for LDAP.

I could extend the list – but it is not about the limitations of LDAP. LDAP has done a great job for years but there is obviously the need to do the next big step. An interesting foundation for that next big step comes from Kim Cameron, Chief Identity Architect at Microsoft. He has developed a schema which he calls system.identity. There hasn’t been much noise around before. There is a stream from last years Microsoft PDC, there is little information at the MSDN plus a blog post, there is the Keynote from this year’s European Identity Conference. But it is worth to have a look at that. The approach of system.identity is to define a flexible schema for identity-related information which can cover everything – from local devices to enterprise- and internet-style directories, from internal users to customers and device identities, including all the policies. It is, from my perspective, a very good start for the evolution (compatibility to LDAP is covered) well beyond LDAP and today’s directories.

I’ve put the concept under a stress test in a customer workshop these days. The customer is thinking about a corporate directory. Most people there are not directory guys, but enterprise IT architects. And they definitely liked the path system.identity is showing. It covers their needs much better than the LDAP schema. That proved to me that system.identity is not only for the geeks like me but obviously for the real world. Thus: Have a look at it and start thinking beyond LDAP. The concept of system.identity, despite being early stage, is a very good place to start.

One of the really interesting announcements in the Cloud space these days has been from VMware and Salesforce.com with their vmforce offering. Their claim is “The trusted cloud for enterprise Java developers”. Correct. It is a cloud environment where Java developers can build apps with a Spring Eclipse-based IDE, where they can use Tomcat, and so on. Thus there is an environment do build and deploy Java apps in the cloud.

Beyond that, force.com functionality might be used. That is definitely interesting because force.com provides a lot of services around business analytics, reporting, mobile device support, and many other functional areas. That might speed up development significantly – sort of rapid development support in that environment.

However, the most important point from my perspective is that vmforce is much more open than force.com itself. The force.com platform is proprietary – and that equals to lock-in risks. Thus users have to analyze whether the advantages of rapid development, the force.com database, the force.com services and so on are worth the lock-in in the sense of very limited portability.

When choosing vmforce, developers can build Java apps in a standard environment. Thus, they can avoid these lock-in risks. If they opt to use force.com services, they have to pay a price in the sense of using specific services from a specific vendor. However, with a good software architecture the apps can be built in a way that allows replacement of force.com-specific features by other services.

With the combination of force.com and vmforce, Salesforce offers choice to developers – from a more closed, very rapid and efficient environment to a very open, but a little more complex environment plus the option to combine that in a flexible manner. That makes sense, from my perspective. And it is definitely worth to have a look at vmforce and to play around once they will provide their preview versions this fall. That is, by the way, a negative point: We are still some time away from production use of vmforce.

During the last weeks, with all the discussions about security- and privacy-related issues in social networks like Facebook or SchülerVZ, I’ve had some talks with people. My position is that these issues are a result of bad software architecture. The counter argument sometimes has been that when building these networks the focus has been on functionality, not security – and that the business model of these networks is based on the functionality. What was meant by that is that you should first care about functionality and that security is somewhat irrelevant because it doesn’t help you in achieving your business goals.

However, that is fundamentally wrong. The current issues prove that the business model of these social networks is threatened by security weaknesses. They also prove (like any good software architect knows) that it is virtually impossible to add good security afterwards. You have to build it in from the very beginning. Trying to fix issues by blacklists or whitelists or by adding some URL obsfucation or something like that always will address symptoms, not the cause.

What we currently observe at many social networks and eCommerce sites is that there is more attention on security and privacy issues – and the providers are struggling with this because their software security architecture doesn’t allow to flexibly react on this. For sure some of these providers are somewhat reluctant in changing their privacy and security settings because their model relies on “openness”. Anyhow, even Facebook has had to make changes, and that will continue.

Good software security architecture would allow these providers to just change some settings by configuration. That would be easy and not very expensive if the software were well constructed, with security in mind from the beginning. That includes the ability to flexibly use different authentication mechanisms and a consistent authorization model which is configurable. For sure there is some more work to do in architecting and developing such a system – but it is significantly less work than trying to fix problems afterwards (and, besides this, doing it from the beginning is a solution and not a patch which leads to patchwork with security and privacy holes).

However, the most important lesson one can learn from that situation is that software security is relevant to any business model. If it inhibits growth, if it leads to a loss of trust and in consequence of users then it affects the business. The  argument that it is first about time-to-market isn’t really valid. It doesn’t take much more time and efforts to do software security right then to ignore this – especially because some security always has to be added before releasing a software. The real valid rule is: You always will pay for bad software architecture. And you will pay for bad software security architecture. That is like in real life architecture and construction – go back to the bible, even there it is told that you shouldn’t build your house on sand. Ignoring software security at the beginning is nothing else than building houses on sand. And a good business model which thinks strategic doesn’t ignore that fact.

Building software without a good software architecture is sort of building a car without breaks. You can argue that the car is for driving, not breaking. And you can argue that it is about functionality not security. But would you trust in a car without breaks?

EIC 2010 has ended. And like each year, there are some interesting observations. I’ll take three of them:

1. The “classical” IAM topics like provisioning or E-SSO are well understood now – and extended.
2. Federation becomes reality.
3. The cloud impacts IAM – and vice versa.

Topics like provisioning and E-SSO were discussed mainly in the many “Best Practice” sessions. There are many implementations out there. Several of them use MSSPs (Managed Security Service Providers) or other Saas-/Cloud style types of deployment. And they are increasingly integrated with other IT infrastructure elements like the ITIL tools or portals. There is an evolution towards more integrated approaches and thus more architecture options, and it is obvious that the cloud starts to impact this as well. In the area of E-SSO, trends towards more versatility and integration with for example strong authentication technologies as well as the emerging topic of convergence (physical/logical) were the most important ones discussed at EIC.

Federation is becoming reality. It isn’t hype anymore – which is a good sign. Interestingly, the federation sessions I’ve attended at EIC as a panelist or speaker were fully packed – a difference to last year. The value of federation is understood – now it is about implementation.

With the separate Cloud Computing track and the parallel Cloud 2010 Conference we had this year, there was as well a lot of attention on Cloud Computing topics. These sessions were as well crowded. The most important topic was the relationship between the Cloud and IAM/GRC. There were many interesting, though provocing sessions and many practical views, beyond the hype towards the real thing: How can we make the Cloud more secure? And how can we do IAM/GRC in the cloud for internal and external environments? And there were valid answers, not only questions. It was sort of “The Cloud brought down to Earth”…

I’ll blog about many of these aspects more in detail over the course of the next weeks.

Microsoft has introduced the concept of claims-based securitywith it’s “Geneva” project. Claims are sort of attributes which are provided by identity providers in the form of tokens and consumed by applications. In fact they are one way to make federation easier and more user centric. “Geneva” provides the tools at all levels to work with claims. The concept of claims is used by some other groups at Microsoft and we probably will see several Microsoft applications with support for claims within the next months.

However, the biggest impact might be on the Windows operating system itself. Claims could make that much more flexible from a security management perspective than today’s mainly ACL-based security model. ACLs are too static and too complex in management to really fulfill the customer needs today. Not only in Windows, but in other operating systems as well. If you think about an operating system which consists of services (Service Providers, Relying Parties) and relies on Identity Providers to provide claims, the entire Security Management can become much more efficient. Based on Policies, using dynamically provided claims. Authorization might be done by the services based on policies and claims or by specialized authorization engines within the operating systems on behalf of the services (the latter not yet being part of “Geneva”).

It is, without any doubt, not that easy to perform such a fundamental change. ACLs are at least somewhat understood, claims are new. There has to be a migration path and compatibility. But if we look at all the options we have, claims appear to be the most promising concept for the future security at the operating system level. One interesting side effect is that the same policies might be applied to other elements in the security infrastructure as well – external access management tools and so on.

Meet me at European Identity Conference 2010 and Cloud 2010 Conference, Munich, May 4th to 7th.

I’ve done several webinars around changing architectures for Identity Provisioning and Access Governance during the last few months. And new architectural approaches for Provisioning have been an important topic at the EIC for years. I’ve also written a report on Access Governance architectures recently. That is no surprise. Provisioning has to integrate with IT Service Management in some way. It has to support the standard systems where automation is key as well as other systems which either don’t support automation interfaces (unfortunately there are several apps out there which don’t provide integration points, including several important healthcare apps) or where automation is too expensive. Thus, it is not only about connectors. It is about a flexible support for different approaches, from manual workflows to full bi-directional automation.

For the core systems, it definitely makes sense to automate. Many transactions, high risks – these are reasons to invest in direct connectors. But there are many other systems out there which need to be connected as well. Even while there aren’t that many standard interfaces (Web Services, Command Line Interfaces, JDBC/ODBC, LDAP,…) which are commonly used to interact with target systems, the customization and integration is costly anyhow. “Connector fabrics” and other approaches help, but typically organizations end up with some systems which are tightly connected and others which aren’t.

There are many approaches to integrate these systems. There might be specific provisioning tools (FIM/ILM, Quest ARS, and others for Active Directory; SAP NW IDM for SAP;…) in place which can be integrated with other provisioning systems. There might be existing processes based on SRM (Service Request Management) tools. There might be the need for additional manual workflows and some access governance to track whether the manual actions have been performed or not.

With other words: Flexibility is key. Flexibility for architectures, where Identity Provisioning and Access Governance tools are just one element – there might be more than one Provisioning tool, there might be SRM, existing workflows, the integration of Provisioning and Access Governance, interfaces to Enterprise Portals, and so on. And flexibility for connections to systems, by not only relying on automation.

Interestingly, I had some briefings in the last few weeks where vendors – like Courion and Aveksa – highlighted new capabilities which are exactly targeted on this. There are other vendors which started with that before. However, it seems to become a major trend right now – open, flexible architectures for Provisioning and Access Governance. For customers, that means that they have to think a little more about the adequate architecture. On the other hand, that might save them significantly more money by choosing an approach which really fits to what they have.

Hope to see you at EIC 2010 in Munich, May 4th to 7th, 2010.

In my recent post on versatile authentication I touched the topic of national eID cards. Some two weeks ago, I did a presentation on eID interoperability from a private perspective. I started with the question about why strong authentication technologies are still not widely used. The vendors might claim that they are, but in fact we still mainly rely on weak approaches like username/password, PINs, PIN/TAN, and so on.

One reason for that is that approaches which are reusable need a sponsor. Many companies in eBanking, eCommerce, and other areas understand the need for strong authentication. But they don’t want to rely on proprietary mechanisms. They don’t want to deploy and provide the logistics for advanced mechanisms due to the costs associated with. And they don’t want to invest in a technology for their customers which then might be used by their competitors as well. One example for the latter situation are readers for cash cards, amongst others.

For sure you could argue that the example of the UPU (Universal Postal Union) has demonstrated some 145 years ago, that this isn’t a valid argument. Before UPU, there had been a complex system of billing between postal agencies in different countries. They counted the letters and the fees and billed each other. The basic idea behind UPU was, that there is usually one letter back per letter sent, thus the fees which have to be payed are more or less equal. Thus it is much cheaper to just not do that billing anymore and to have the senders pay only a fee in the originating country of the letter. This system works for a pretty long time right now. And I don’t have that many doubts that a standardized system which requires some hardware to be deployed would work as well when everyone supports his customers – the ones with fewer customers will pay less on average because they have to deploy less, the ones with more customers will pay more.

Unfortunately I neither see a standard solution which is accepted by everyone nor the willigness to do that. Thus we need alternatives. And that is where eID cards come into play. There is a potential for mass adoption at least in countries where it is mandatory to have such a card. However, that requires that these cards can really be used for strong authentication in eCommerce and other areas. And that, again, requires the deployment of readers for these cards.

Thus, we need someone to sponsor at least the initial deployment to build the critical mass. The only ones to do that are the governments, like in Germany, where 1.3 million readers will be sponsored. That in fact is business development, because it enables the use of Internet-based services with strong authentication. It enables new business models, efficiency in organizations, it will reduce fraud and the associated costs. However, the eID projects usually aren’t seen from that perspective of business development – private use cases are more sort of an add-on. Decisions like in the Netherlands to shift such projects to a later point of time show a lack of understanding of the potential economic impact.

We need mass adoption of reusable strong authentication for the “Internet business”. The only way to achieve this is by sponsors who invest in the mass adoption of technologies. And the most likely sponsors are governments, as part of what they do for their economies and their competitive advantage. Once we have a mass adoption of strong authentication, we might see additional technologies being used for graded and step-up authentication. Vendors of versatile authentication and context-based authentication/authorization will benefit from this as well because eID cards will always be only one of many accepted means of authentication. But the ones who benefit most are the businesses themselves which can reduce fraud and implement new business models.

Visit EIC 2010, Cloud 2010, MIS 2010.

There are a lot of talks about making our planet smarter. Despite being far too much fiction, the film “Die Hard 4.0″ has been around some of the potential risks around this. I recently had a very interesting discussion with a forensic/incident expert from the US. We’ve discussed several issues and ended around the idea of this “smarter planet” and the “smart grid” as one of its most prominent elements. Per se, the idea of having a networked infrastructure in many areas, with a high degree of flexibility and increased service availability is as appealing as inevitable – things will go that path.

However the security of that future seems to be somewhat ignored, at least in the public discussion. For sure politicians aren’t interested in the dark site of things as long as the bright side is discussed. They don’t want to be the party poopers. Only if there is an incident, they will claim that they have done everything to avoid it and that everyone else is guilty but not them. Vendors, on the other hand, are mainly interested in driving things forward. Most of the for sure don’t ignore security – but it seems to be more sort of a pain than an opportunity.

Thus, we observe currently the same thing in big like we can see day by day in small: Security is ignored when driving things forward. That is true for a tremendous part of the software which is developed, it is true for new standards in IT (think about web services – security has been missing at the beginning), it is true for so many other areas. And now the same thing seems to happen for all these smart things. But, from my perspective, then these things aren’t really smart.

Just think about the smart grids. This is sort of a massive data retention mechanism, collecting and networking millions of households with the utilities. There are privacy threats – who has used which electric device when? There are new attack surfaces. For sure there are some things going on around security. But from what I observe, security is developing slower than the rest of the things in the smart planet initiatives. It’s sort of a ticking time bomb out there.

What will happen? Security is undervalued. For sure it isn’t ignored but it won’t have the relevance it should have in these projects. People will cheer when there are some results of projects delivered. Security will become a problem. There will be unpleasant discussion about who is guilty or not. Security issues will be patched. To some degree. Wouldn’t it be a better idea to built security into the concepts from scratch? To really have a smarter planet at some point of time?

Sorry for being the party pooper!

There are so many myths out there about Cloud Security – time to start putting them away…

1. The cloud is inherently insecure. No, not really. There are providers which deliver a high level of security. The cloud can be more secure than internal IT, given that services are frequently operated very professional.
2. The cloud is more secure than the internal IT. No, as well not. The cloud is neither secure or insecure. It is about the single service which might be more or less secure. And it always depends on with what you compare, e.g. how strong security in the existing internal environment really is. Thus, it is important to define security requirements in service descriptions and SLAs and to measure security.
3. Cloud Security issues are new. No, most of them are not. They are the same like in outsourcing or the tactical use of external services we are doing for years right now. The difference is that there are much more services to deal with – which is an opportunity to handle security in a standardized way and improve it beyond the typical ad-hoc approaches of the past.
4. Security is the task of the Cloud Service Provider. Yes and no. Service providers have to provide a high level of security and they have to inform about. But you can’t just rely on them. You’re always the one who defines his security requirements and is responsible for their fulfillment – by chosing appropriate service providers.
5. We can’t do things outside of the EU. A myth. There are some legal aspects around operations on privacy-related data which have to be observed. But overall it’s not about that things can’t be done but more about a big grey area of uncertainty.
6. SAML solves the IAM issues in the cloud. No, definitely not true. SAML is the first little step towards the target of externalized security of cloud services. But that’s only about the separation of administration and authentication. The much more interesting topic of authorization (XACML and other standards) has to be solved as well. And few cloud service providers support XACML today. Few support own proprietary web services as an alternative. Not to speak of auditing interfaces…
7. Security in the cloud can’t be measured. Somewhat true – in the sense of: Most providers don’t support risk metrics, a detailed auditing and so on. But theoretically not true, because these interfaces can (and should) be provided.

More on Cloud Security and some of the myths and real issues in the KuppingerCole Virtual Conference on Cloud Security. Register for free!

And for sure at Cloud 2010, parallel to EIC 2010.