These tools are important to enable a detailed analysis of access rights at the level of files, folders, and shares – when looking at file servers. Provisioning helps us to ensure that a user has an Active Directory account and is member of some specific groups. But what are these groups allowed to do – in detail? Some Access Governance solutions might provide some details, but typically not as specific as the expert tools in that area can do. And there are many tools out there. These days I spoke with Protected Networks, but Econet, Tesis, and ASB - to mention just some German vendors – can deliver on this as well, with somewhat different approaches and capabilities. And these are just some examples.

From my perspective, we need a layered approach – Enterprise GRC, Access Governance, Provisioning, and the specific tools for different important application environments. And we need to integrate these tools. That will enable organizations to fulfill the governance needs and compliance regulations at all levels – with an integrated approach and avoiding investing in point solutions.

By the way: If you as a vendor feel that you fall in that category (for AD and file servers, for SharePoint, for SAP), just keep us informed. We might have you on our watchlist but given that this is a market with many smaller vendors in, we might have missed you until now…

Amongst these products are solutions which enable web site developers to quickly integrate registration features which rely on social networks such as Facebook – use your Facebook account to register… There are several other services on top of this. But there are as well capabilities for stepping up in the authentication depending on the types of interactions and transactions someone is doing.

JanRain has managed to find an appealing and obviously successful business model around identity services. They are not focused on any particular type of authentication like Information Cards or OpenID but provide the frameworks to deal with all these different approaches. And that is exactly what most organizations need today when building their online presence: Flexibility in dealing with different online identities and an user-centric approach which allows users to quickly and easily register. JanRain definitely is worth a look for any web developer and especially for all the people responsible for online marketing.

SAP is commited to SAML (Security Assertion Markup Language) for a while now – and SAML 2.0 support is found at many places in the SAP portfolio. SAP systems can act as service providers in federation scenarios, with SAML 2.0 enabling the Single Sign-On and sharing of identity-related information. Using the identity provider within SAP NW IDM 7.1 SP 5 (to keep the name short and make it even more cryptic) allows to use a centralized view on identities within federation. The product can provide the unified view on identities which is a foundation for federation. Without identity information quality, there is no successful federation: Garbage in, garbage out.

The enhancement of the product shows where SAP is heading: It is a central element within the SAP NW infrastructure which provides all the identity services required in that infrastructure. There is tight integration with SAP products, but as well support for standards to integrate external applications – like with SAML 2.0 and the inherent support for Non-SAP service providers as well.

The other important enhancement in SP 5 are the Identity Reporting Capabilities based on SAP NetWeaver Business Warehouse. That enhances the reporting capabilities of SAP NW IDM 7.1 – but it requires to have the Business Warehouse product in place. Anyhow, the enhancements clearly demonstrate the strategy of SAP for NetWeaver Identity Management: A central piece in the SAP infrastructure, well integrated, and with standards support. The enhancements demonstrate another point: SAP is executing on its strategy consequently. Maybe a little too quiet, but they are moving forward.

Besides this, the options for managing “authorizations” or privacy settings, e.g. controlling who is allowed to see what are primitive. I can share everything with my friends. But in many cases I want to share some informati0n only with some of my friends. I can use lists, but I for example can’t use these lists as sort of “groups for ACLs (Access Control Lists)”. At list I didn’t manage to find out how until now. But given that I have friends from business and from my private life, it is very obvious that I won’t share everything with everyone, isn’t it?

Again, like pointed out here and here, there is no reason not to construct social networks secure and with strong privacy settings. For sure it is hard to do it afterwards, once you have a bad security architecture in place. But technically seen, it is feasible – and it is relatively easy. But it requires understanding the needs for privacy (which become an inhibitor to the market for Facebook at least in some countries these days) – and you have to do that.

Why am I using Facebook anyway? Too many people are using it and many said that it is a better way to stay in touch with contacts than the other social networks like Xing or LinkedIn. And, by the way: These other networks are as well not the godfathers or inventors of privacy… I don’t expect Facebook to ever understand privacy and act accordingly. Thus I’ll keep an eye on what I publish there and what I don’t publish and I’ll keep my privacy settings very rigid. For sure I could use more than one Facebook account. But that would be harder to manage and a pain for the ones which are “friends” in private and business life.

Just a side note: Interestingly many startups have significant lacks in their overall software architecture and struggle with things like scalability and adding new features. And even more struggle with increasing security requirements. One reason is the missing understanding for security (see link above). The other is that many startups have CTOs which are pretty inexperienced – interestingly the ones where the founders (and amongst them the CTO) is doing a startup the second or third time perform much better because they have learned many lessons before. There are – like always – exceptions from that rule, e.g. startups with young CTOs doing a very good job. But these are the exceptions. You could bet on what my rating for Facebook is from that perspective…

By the way: If anyone knows how to control all access to the content in Facebook based on my lists of friends, let me know…

• Cloud: An IT environment to product IT services.
• Cloud Computing: Making use of these services – procurement, orchestration, management,…

Thus the internal IT can be understood as one of many clouds, there might even be multiple internal clouds. But we don’t have to care that much about internal, external, public, private, hybrid,… The prerequisite for an IT environment to be understood as a cloud is the service orientation, e.g. the production of well-described services. That might be done in a more or less scalable way – but it is about services.

Based on that, the sometimes discussed analogy between the Industrial Revolution and Cloud Computing is acceptable – one has to be careful with analogies because most of them have weaknesses. When looking at the concept of Cloud Computing, it is about the optimization of service delivery, based on orchestrated services (1 to n services) out of 1 to n clouds. The target is to provide the most adequate (which is a result of cost, availability, governance requirements, and many other factors) “service supply chain” to fulfill the business needs.

To do that, services must be produced efficiently. That is where automation comes into play. The internal IT environment acting as a cloud has to be efficient. Automation is a key element for efficiency. Virtualization might help as well, but efficient virtualization requires a lot of automation.

The industrialization paradigm, on the other hand, is valid when looking at the entire picture:

• The production of services (goods, parts) is automated.
• New services (goods) are built based on parts which might be delivered by external suppliers.

Overall, the most important thing about Cloud Computing is that it changes the way IT services are provided to the business. There are standardized concepts for manging services, there are standardized descriptions, optimized production (using automation, amongst others), better planning, flexible orchestration,…

From an organizational perspective that leads to two different layers of IT organizations within organizations:

• The management (procurement, orchestration, auditing,…) of services, which builds on services delivered by clouds to produce the final service which is required by the business.
• The production of IT services, internally or externally.

One might discuss whether the specific services which are required to glue “standard” services are at the higher or lower level – you can understand them as part of the orchestration or as “custom” services required for orchestration and provided by some service provider. However, it is obvious that IT organizations have to change into an “management and orchestration” and a “production” unit, sort of the same basic structure like the organizations have overall. To make the most out of Cloud Computing, CIOs have to start this change now. And, honestly: It is more likely that production will be externalized – but on the other hand there is plenty of room for providing specific services in an efficient way.

When looking at Völcker customers, there shouldn’t be much FUD. Völcker will continue it’s development in Germany and the leading people will stay on board. Even more, Völcker will have significantly bigger resources available – and given that Völcker is very innovative and has also a strong understanding of IT Service Management, the customers should benefit from that. Beyond that, Völcker as part of Quest is a global player instead of a Hidden Gem which is “world-known in Germany” only. With other words: There are many opportunities and I don’t see much risks. For sure an integration process might slow down things a little. But Quest is experienced enough in integrating acquisitions to mitigate these risks.

On the other side, there are the Quest ARS (Active Roles Server) customers. What is in for them? Quest ARS started as a tool for better, role-based management of Active Directory environments. Today it supports also some other systems. However, it is still Active Directory-centric. Quest has stated that both tools, Völcker ActiveEntry and Quest ARS, will play a vital role in their further strategy, with strong integration between both tools. Thus, Quest ARS remains a strong solution for Active Directory environments. And if it is about heterogeneous environments, ActiveEntry comes into play. It will be interesting to see how much Quest will invest in ARS support for heterogeneous systems. That probably is a slight risk for customers. But overall, the risk is relatively low.

Chances are good that this turns out to be one of the acquisitions where customers of both parties can benefit in the future. The reason is simple: There isn’t that much overlap between the portfolios. And, from the KuppingerCole perspective, there is much more potential for synergies well beyond IAM and Identity Provisioning.

By the way: There are several reports available at www.kuppingercole.com/reports – on Quest products as well as Völcker products, and there is the Hidden Gem report which covers Völcker as the not-so-hidden-anymore vendor.

For sure I like it when a Hidden Gem becomes “more visible”, because it proves our rating of these vendors. So I’m looking forward to see who is next.

Right now, they are one of the vendors in the market which have solutions in most of the areas of IAM. They have one of the (from a technology perspective) definitely leading-edge products in the markets for identity provisioning. And they have a lot of complementary solutions. Beyond that, ActiveEntry fits very well into the Quest portfolio by supporting Active Directory environments at a high level but going well beyond that. Thus, it is sort of the perfect fit.

Quest right now is a full competitor of the big and established ones in the market like Oracle, IBM, Novell, and the others. It is in an interesting competitive position regarding Microsoft, Omada and related vendors. And, if you look at the number of people working around IAM, Quest is also from that perspective one of the vendors with the biggest potential in the market. With other words: This acquisition will heavily affect the IAM market and Quest will be one of the vendors to really take into account now.

There are several reports on Quest and Völcker from KuppingerCole available at www.kuppingercole.com/reports. Have a look at them (or ask us for advice…).

When talking with end user organizations it becomes obvious that we are far away from that state. There are implementations of different directories, and most of them work well for their specific use case. But once it comes to optimization, the situation changes. What to put in the Active Directory, what not? How to optimize the way applications are dealing with directories? How to best build a corporate directory or a meta directory (the directory as data store, not the meta directory service as technology for synchronization!)? How to interface directories for specific use cases and how to best retrieve information?

There are many aspects to discuss and to understand to end up with an optimized “directory infrastructure”. First of all, it is important to understand which directories you have and how they are used – usually there are far more directories out there than you’d expect. And I’m not only talking about the Active Directory, eDirectory and all the LDAP servers, but as well about “de facto” directories in the form of tables in databases and so on. I’m talking about anything which acts as a directory. That includes the application directories, which might be hundreds of small directories. And they sometimes contain sensitive information like privacy-relevant data. Besides this, they frequently have somewhat redundant data. Based on this analysis, you can drill down and identify which attributes have to flow between which directories in which use cases.

The latter is more about really optimizing your provisioning. The analysis is, on the other hand, as well a good foundation for optimizing your directory infrastructure. Where can you avoid redundancy?

Based on such an overview, you can think about some other aspects:

• Which central directories do you need for which use cases?
• How to optimize application access on directories?
• Where do you need specific technology for these directories beyond standard LDAP?

There is always a need for some more or less central directories. The Active Directory or eDirectory are examples, used for the primary authentication of internal users and for many infrastructure services – but they can’t do anything. There are Corporate Directories for centralized access to corporate information. There are more technical meta directories as the “source of truth” about distributed information.

We have to think about optimizing the application directories. One or few centralized directories together with Virtual Directory Services which are offered for example by Radiant Logic, Oracle, and Symlabs are an interesting option do build such a centralized yet flexible infrastructure, with the Virtual Directory Service as interface layer.

And we have to look at specific use cases where we need specialized technology. There are some innovative vendors out there. UnboundID for high scalable environments, where others like Oracle, Novell, Siemens, and so on are active as well. eNitiatives with their ViewDS services for strong querying capabilities and the ability to easily build interfaces in a “yellow page” style to these directories.

My experience is, that there is still a lot of need to think about directory services – and there is a lot room for improvement in most IT environments. What is your view on that topic?

When BAM became a hot topic some 10 years ago, the implementations were nothing else than a little advanced analytics. That was, at that point of time, far away from my expectations which were around intelligent, automated, real-time and ex-post analysis of relevant activities in business systems and the identification of critical changes which require intervention. For sure automated reactions as well as alerting should be part of this.

The term BAM came to my attention again when talking with MetricStream recently. MetricStream is one of the leading-edge vendors in the GRC market. They are one of the “Enterprise GRC” vendors (Business GRC would be the better term). But in contrast to many others, they allow for a tight integration with IT systems and IT controls. Based on that, they are able to use automated controls of virtually any type and map this into their system. That in fact allows to integrate what I had expected from BAM years before with a holistic GRC approach. By the way: MetricStream has a pretty high rank on my list of GRC vendors…

When looking at the BAM market I have to admit that there has been evolution since the early years of BAM. There is much more automation than pure analytics, there are several interesting solutions out there. However, MetricStream is somewhat unique with enabling this (without talking about BAM) in the context of Business GRC and thus allowing to add this as a generic approach into what every organization has to do today: Building a GRC infrastructure, with manual and automated controls – where automated controls should provide what BAM has been promising.

I assume that several of you have another opinion – so I’m looking forward for your comments.

• 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?

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.

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.

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?

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.