Single authority principle

Slav — Tue, 15 May 2007 09:04:00 GMT

One of the biggest issues in today's IT architectures is overengineering. Excessively complicated solutions are bound to be less reliable and secure. Any other component in a solution is potential point of failure. Well, not necessarily in terms of reliability (clusters, you know) - but certainly from security point, as it adds potential vulnerability and attack point.

And it creates some interesting issues. An example is a popular approach to identity management: using HR database as a "source of truth" about company staff. The corporate directory (your AD, or NDS) is populated from the HR database, using middleware. If you're using same corporate directory for controlling access to the HR database, that will result in an access management chicken-and-egg problem: who is the authority? Besides, now attackers have two targets for taking control over entire enterprise infrastructure (and middleware, the identity management system, is the third equally important). The approach avoiding that situation is developed centuries ago by the world's military: use single authority.

Using HR database as the source of truth does make sense, as it contains information about those who are paid by the company. However, it so happens, incidents that are most difficult to investigate are not caused by paid staff using their own accounts. Few years ago the security industry was shifting its focus towards malicious insider. But recent events prove that classic intrusions without apparent access abuse are still big threat. Take TJX and their insecure wireless network. Nevertheless, we should soon see more close integration between business systems like HR, identity management solutions and corporate directory. Oracle is making steps in that direction already. I like Microsoft's Active Directory and would like to see some effort in that echosystem as well.

But that is a move towards identity and access management based on military principle. It would be very interesting to see a system that is based on democratic principles. That is unseen so far but may well be an interesting change in the enterprise space.

Architecting enterprise for federated identity

Slav — Sun, 18 Mar 2007 03:44:00 GMT

InfoCard is the way to go. The concept is very well engineered. It is commonly accepted by various influentials of the IT industry, and some other industries (think of showbiz); it has a number of open-source implementations, as well as Microsoft one (known as Windows CardSpace); and Kim Cameron is a legend. The missing layer of the Internet - the identity - is now found.

So where are the adopters?

Today, there aren't any of importance (measured by monetary value). The reason is the enterprises, and their ways of architecting their systems. There are two issues - actually, two sides of the same problem:

Enterprises are designing their identity management systems and applications assuming they will be in full control of the client identity; and
Application service providers are not ready to accept identity assertions issued by other parties - instead, they issue their own, sometimes providing limited delegation.

When talking about the application service providers (commonly referred to as just ASPs), I don't mean it in the pure dot-com sense. Taking into account various B2B scenarios, there are much more ASPs than most of you think - in reality, most enterprises provide access to their applications to other parties.

And we have a problem right there. If I'm an organisation that is using a 3rd-party application for my staff and customers, I still need to be in control of their access to the application. If I give access to a 3rd-party, I want a way that allows that party to manage their access the way they do that, and I don't want to carry the burden of co-managing and supporting access control for other organisations. InfoCard solves the problem. Enterprise applications and identity management systems should be designed for the Identity Metasystem.

They aren't yet. Enterprise architects must adopt the new paradigm, ditch few utopian concepts (i.e., single customer view) in process, and actively confront empire building and control freakdom that plague enterprises today. The outcome is worth it. Think of simplified B2B relationships and acquisitions. Think of new ways of doing outsourcing.

Support from big names is needed. Big business looks at Oracle and SAP to make the first step and make their products (and, not less important, hosted solution offerings) compatible with InfoCard. Microsoft has to walk the talk and start offering support in the server and business software (I'll be looking at the Intelligent Application Gateway and Hosted Messaging and Collaboration and CRM solutions). And those offering identity management solutions - Microsoft, IBM, Sun, BMC - should also provide support.

But for now we have a catch 22 situation - everybody's waiting for everybody else. Well, Microsoft is in front again, but that's clearly not enough. Alternatives to the Identity Metasystem look solid - just like SNA looked good compared to TCP/IP some 25 years ago (scalable, secure and supporting QoS - yet mainframe is required). Alas, you'll be making a mistake if your solution isn't compatible with the Identity Metasystem today.

Risque Management : Identity

Single authority principle

Architecting enterprise for federated identity