Active Directory for the cloud? Is it a security nightmare?

Microsoft has revamped Active Directory for the cloud but has it fully allayed security fears?

There’s often a distance between theory and practice but in the case of Cloud Identity management the gap is so wide, you’d have to be an Olympic class long jumper to bridge it.

There’s plenty of jostling for space in this arena. Microsoft has grabbed the agenda by launching, and then theorising, about the way its new Azure Active Directory Service (WAAD) might make life easier. However, as soon as you start to think about the topic you do end up asking yourself – easier for whom?

Everyone agrees that authentication and identity of users is a hot topic – and an important one. This has nothing to do with cloud, it relates to a time when cloud was a fluffy white thing up in the sky – the notion of a user data repository within a business can be found in all manner of perfectly usable, but superseded, LAN OSes stretching back to the 80s.

Greybeards may recall that Microsoft Active Directory was a counterblast to Novell Netware, when it seemed centralised private identity repositories were the way to go – although a better word order is private, centralised identity repository: the difference between a copy of your town’s phone book and your list of those people who have the alarm combination for your place of work.

The problem facing all companies is that the slightest crack in the security features leaves the possibility of chaos. It therefore is important that vendors offer customers something as near foolproof as possible. The fundamental cloud-facing architectural decision at Microsoft seems to think that we’ve reached that situation. Once you have a platform as statistically reliable as Azure, then it’s ready for the most sensitive information.

The source materials on this project make it look much more insidious than that, with convoluted diagrams of grand, cross-resource federated single sign-on so that the authenticator with the most market clout becomes the default source of authority – which in this case, is Microsoft.

This is not a situation that has been well-received by many industry bloggers, many of whom are much pre-occupied by security (and even more pre-occupied by Microsoft’s pre-eminence in the enterprise software market).

However, I think the paranoid reactions found in a wide swath of blogs are an over-reaction; mostly riding on the back of more nomenclature problems which commonly attend cloud announcements like this. Federated identity lookup isn’t new: even AD lookup is trivially and frequently employed by SaaS vendors such as WebSense, from back before SAAS was a hot acronym.

The fact is that there’s a world of difference between having just one ID anywhere in the world ever (the fear) and the nature of being given a username and password inside your new company, and losing the one from your previous employer (the reality).

Most existing Active Directory deployments you will encounter are from businesses providing authentication and identity for their employees, not SaaS vendors or old-school web-hosts purporting to be final-resort identity brokers on a “one human, one password” type of basis (yes, Google, I am thinking of you, though the same could be said of Paypal).

Microsoft’s presentation materials on Azure Active Directory are a pretty long way from the kind of lifetime online identity evangelism you see from the big end-user service specialists. In cloud-speak, people are nervous about an all-encompassing identity management within PaaS services. However, Azure Active Directory is much closer to SaaS, in other words a construction kit, made from cloud instances on Azure, something that should be well understood.

The part where I do share the scepticism, however, comes in considering just how far businesses can go with authentication of any kind that "reaches out" across a connection, to another company.

The promise of cloud login that’s the same as your company login isn’t a trivial barrier but I question whether this is a cloud issue as such. I see it as more a matter of a logical extension to your physical security boundary, in other words, it’s a job in network topology. Microsoft believes that, as a website owner, you will re-acquire authentication for a member of a client’s staff ordering a service by interrogating the employer/client’s distant, point-to-point communicating Authentication Repository.

This goes against accepted custom and practice in E-Commerce. After all, as the interrogator of that distant verified list of authorised e-commerce transaction initiators, you have very much more to do with their existence and their spending habits, than just knowing they are on the "OK list" at customer #754. These kinds of pressures and priorities argue against the more advanced, more all-encompassing SuperAuthenticator vision which seems to be attracting everyone’s attention.

To cap it all: those paranoids might have a point, because the Live ID system, which manages your use of Microsoft’s online services from XBox to Hotmail to TechNet. In the great ranking of creepily intrusive megaservice identifiers, which present a must-have, no-option monolithic interface to an ill-informed general public: the Live ID system is as bad all the others.

To take an example. I certainly didn’t expect to find the credit card details I’d put in for online game credits with the XBox to be referred to when I started instantiating Azure VMs, because in my case I wanted to use a credit card with a very low credit limit for XBox, and a completely different source of funding for the Azure instances. Live ID didn’t let me do it - or more accurately, it popped up in a friendly way and said it already had details for me.

It’s that kind of creep which makes people nervous of ever larger structures - but nothing I can see about WAAD makes me believe this is the cunning plan. It’s for businesses rather than individuals, however, expect the concerns to remain for some time.