I saw a marketing brochure the other day that claimed “Today’s average enterprise utilizes 16 different directories,” touting their synchronization engine for provisioning and de-provisioning. The vendor’s take seemed to be that 16 was a huge number, but I merely chuckled to myself. Fifteen years ago, while barnstorming the US for a provisioning vendor I would frequently ask the audience how many identity stores they’d identified in their organization. I still remember one memorable response: “we’ve found 116, but we’ve only just started looking.”
Ten years ago, soon after the Liberty Alliance introduced the concept of “federation” as a way for partners, clients, vendors and others to share authentication and authorization, I discovered – again, by asking users at a conference session – that one of the major uses of the federation technology was to connect the different parties after mergers and acquisitions so that the newly formulated organization could do real business while the IT department caught up with the different, disparate and often unconnectable systems that existed in the various parts of the enterprise. The standout memory here was one of the “big 5” US banks who had acquired a small, community bank in California which was still running one update program on an old (i.e., pre-1980) Z-80 single-board machine which couldn’t be integrated with the bank’s network nor was it viable to re-write the software. They never did find a way to connect it directly to the bank’s systems.
All this is to say that by early in the 21st century, both synchronization and federation were being used to connect various identity data stores throughout the enterprise. As for data stores located “beyond the firewall” (back in those days there really was a firewall around the enterprise network), very little was being done. What had been called “web services”, and which was now morphing into “software as a service”, wasn’t much involved in the movement of identity data yet, although it was certainly much talked about by analysts and pundits.
At this time, too, simplified sign-on (SSO) was largely confined to systems within the enterprise even though there was a lot of talk about SSO for web services.
Provisioning for what would eventually be called “cloud services” was, essentially, non-existent. Although Business Layers, the pioneer in provisioning apps, had – at the time they announced eProvisionware, provisioning for the enterprise – promised that provisioning for external users and apps would be coming “real soon” it still hadn’t occurred 5 years later when the company was acquired And its products disappeared.
Ten years ago, when Service Provisioning Markup Language (SPML) was launched, one of its tenets was that SPML would enable cross-organizational provisioning with a vague reference to some sort of cloud-like service. Ten years later, we’re still waiting.
Identity services in the cloud-computing arena pretty much boil down to a choice of federation or synchronization.
We’ll be doing a session at the European Identity and Cloud Conference called "Federation or Synchronization – the Future of the Cloud" featuring Patrick Harding from Ping Identity, Andrew Nash from Google and Darran Rolls of SailPoint, three gentlemen very familiar with these two methods. To kick off that session I’ll be speaking about “What Federation is About – in Theory and in Practice.” So for today I’ll concentrate on synchronization.
Synchronization services are part of the bread and butter of cloud computing. Services such as Dropbox which synchronize file shares between and among various client desktops allow us greater freedom when moving about the world. Dropbox in concert with CloudOn allows me to bring my necessary Microsoft Office documents with me on my iPad – and edit them on that device. But that’s for files, what about identity data?
Directory systems, such as Active Directory, have built in replication mechanisms. Some cloud services take advantage of these to enable easy provisioning of cloud service users. One of the better implementations is – what else? – Microsoft’s own Office365.
Office365 is a cloud-based office productivity service with versions for small, mid-sized and large enterprises. The SMB version (approx. $6/user for up to 50 users) includes:
- Cloud-based email using your own domain name;
- Shared calendars;
- Instant messaging, PC-to-PC calling, and video conferencing;
- Web-based viewing and editing of Word, Excel, PowerPoint, and OneNote files;
- Team site for sharing files; and
- External website
Office365 uses Active Directory synchronization to move user identity information between your datacenter and the cloud space. It should be noted that Office365 can also use a federation mechanism (which Microsoft refers to as single sign-on) which enables your company’s users to sign in to Office 365 by using their corporate credentials. Microsoft recommends you start this way while setting up synchronization – which can take a while.
Synchronization of AD for Office365 takes a bit of preparation, some testing, and a multiphase commit so that you can back away if you want. Once you’ve committed to synchronization it can be difficult to reverse.
In a Microsoft Office 365 environment, source of authority refers to the location where Active Directory directory service objects, such as users and groups, are mastered (an original source that defines copies of an object) in a cross-premises deployment. For example, by running Active Directory synchronization, you are mastering objects from within your on-premises Active Directory. Alternatively, when you create objects by using the Exchange Control Panel (ECP) or the Office 365 portal, you are mastering objects from within the Office 365 cloud.
Office 365 requires a single source of authority for every object. This reduces the likelihood that directory data could be inadvertently overwritten.
By default, Office 365 directory objects are mastered in the cloud, which means they must be edited by using cloud-based tools. You can use the Office 365 portal, Windows PowerShell, or the ECP to create users, mailboxes, contacts, and groups in the cloud directory. All subsequent changes to these objects are also made by using the same tools. In this scenario, the source of authority is in the cloud.
When the directory synchronization tool is activated in the Office 365 Admin page, and after the first sync cycle has been completed, the source of authority is transferred from the cloud to the on-premises Active Directory. In this scenario, users, contacts, and groups are created on-premises and then synchronized to the cloud. All subsequent changes to the cloud objects (with the exception of licensing) are mastered from the on-premises Active Directory tools. The corresponding cloud objects are read-only. Administrators cannot edit cloud objects if the source of authority is on-premises.
Up until the completion of that first sync cycle, you can safely back out of the synchronization scenario.
If you’re interested in the specifics of Microsoft’s synchronization for Office365, you should read “Directory synchronization and source of authority,” which has all the details.
To synchronize your directory data either from a non-Active Directory system in your datacenter or to a non-Active Directory system in the cloud (or both), the cloud service provider needs to invest in a synchronization service such as The UnboundID Synchronization Server. This allows you to synchronize data between and among LDAPv3, RDBMS, and Active Directory data repositories. With the UnboundID server – but not necessarily with others - in addition to synchronizing data with standalone repositories, the server also provides a notification service that allows the service provider’s cloud applications or the customer’s on-premise applications to subscribe to receive messages from each other based upon changes made to monitored directory data, thus providing automated synchronization. Some other vendors’ service requires that synchronization be done manually.
You should investigate whether or not your cloud service provider (or potential cloud service providers) offer directory synchronization services. It’s much cleaner and more complete (as far as supporting the full panoply of IAM services) than federation. But because it can take a bit of time to initiate and fully test before going to production, its best to begin with a federation scheme which at least lets you control adding and removing users via your datacenter provisioning service.
And, remember, you can find out much more about synchronization and federation at the European Identity and Cloud Conference, April 17-20, in Munich. See you there!