Comparing Federated Identity Options for Office 365

In my last blog post I walked readers through the various identity management scenarios for Microsoft Office 365. To summarize they are (a) “cloud identity” where users just login via their Windows Azure Active Directory (WAAD) account with no relationship between those accounts to any on-premise directory; (b) “directory and password synchronization” whereby your users’ accounts and passwords from your on-premise AD can be sync’ed to WAAD, but authentication occurs with WAAD and users have re-enter their same username/password over and over again to access Office 365; and (c) “federated identity” whereby Office 365 authentication occurs with your on-premise AD and there is no re-entering of usernames and passwords. In this blog post I want to drill down on comparing options for scenario (c) — “federated identity.”

Office 365

Microsoft Office 365 Identity Scenarios.
Source: http://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/OUC-B211#fbid=K28sUscQO-e

As Microsoft documents, there are really two options for federated identity for enterprises: go with Active Directory Federation Services (ADFS) or go with a third party solution such as Centrify for Office 365. [As a reminder, Centrify for Office 365 is an easy-to-deploy, Azure-based service that offers the industry’s most comprehensive solution for Active Directory-based single sign-on, user provisioning and mobile management.].

If you look at the Microsoft supplied graphic below (via this TechED prezo), you can see on paper that they line up fairly evenly for Office 365 (but not necessarily if you are running any other SaaS apps — more on that later), but how does ADFS and Centrify for Office 365 really compare?

ADFS - Federation options

Let me break down the comparison in a number of areas. [BTW, please note my disclaimer at the bottom of my last blog post on how I actually don’t see ADFS as a competitor per se, but do feel it is important for customers to know the differences in approaches etc.]

#1 ADFS Requires Significant Investment in Infrastructure vis a vis Centrify for Office 365

Note from the graphic above, there is this line item

Requires on-premises servers, licenses & support

Let’s specifically drill down on that as there is a very big difference here.

ADFS is a software-based solution that utilizes a claims-based access control authorization model to implement federated identity. ADFS was built pre-Microsoft Office 365 / Azure / Windows Azure Active Directory, so not surprising it is very much an on-premise centric solution.

As discussed in this recent Microsoft whitepaper, there are a number of architectural components that need to be deployed on-premise (vs. in the cloud). This web page shows a typical on-premise ADFS deployment, with servers in and out of the DMZ. I won’t go into the guts of the ADFS architecture, but the web page I linked to in the sentence above walks you through it.

Fabrikam, Inc.

Per the referenced whitepaper, to get Federated Identity for Office 365 utilizing ADFS you will have to deploy at least a minimum of 5 servers on-premise (they actually recommend more). Here is a screenshot from the whitepaper of the minimum of what you need:

Microsoft Whitepaper

While ADFS the software is not a chargeable item from Microsoft, it is not “free.” (BTW, I have been quoted by fellow Centrify’ers over the last 8 years or so as using the expression “Free as in free puppies” so there is a long record of me using that expression!) Clearly there is a specific hardware cost associated with ADFS, I would assume well over $20-25k to get 5 dedicated servers. And there is also a corresponding resource cost as well to procure, setup/install and configure ADFS components both inside and outside the firewall. In talking with Microsoft partners, they typically recommend to clients that this takes 3-5+ days of time with someone who as some domain expertise. So we are talking about easily $30k+ of total costs to simply install ADFS.

In contrast, Centrify for Office 365 only requires one piece of software — the Centrify Cloud Proxy Server — that runs inside the customer’s corporate network and does not have to be on a dedicated system. An architectural diagram is shown below, and be sure to compare and contrast it to the ADFS diagram above. The installation of the Proxy Service is about 5 minutes.

Microsoft Whitepaper

So there is little to no cost associated with Centrify vis a vis hardware/resources associated with ADFS, and combine that with the fact Centrify for Office 365 can be one of the three free supported apps as part of Centrify Express, there is a very significant economic difference between Centrify for Office 365 and ADFS.

There is also a major architectural and philosophical difference as well between the two approaches. Clearly whenever a company is trying to move to a cloud-based approach for email and collaboration, part of the goal is to reduce on-premise software and hardware. Thus having requirements that in order to say migrate off 2 Exchange servers to cloud-based email that to get AD-based SSO (which is what users got before with on-premise Exchange — and will expect similar functionality moving forward) customers now find themselves having to replace those 2 Exchange servers with a minimum of 5+ on-premise servers and spend many tens of thousands for additional hardware/software/maintenance/installation. For some this may not be an appealing proposition, especially if you have not previously invested in ADFS.

Hence there is clearly an opportunity here for a simpler cloud-based approach (vs. hardware-based and/or virtual machines-based approach) to federated identity for Office 365, which is exactly the approach Centrify for Office 365 takes. Part of this has to do with when these technologies were built: ADFS was built pre-Office 365/Azure/WAAD and at its heart is an on-premise centric solution while Centrify built its capabilities as a cloud service from the get go.

Let’s talk about a few more differences on this topic of infrastructure required to operate, namely

#2 ADFS requires holes to be poked in your firewall and
#3 ADFS requires 3rd party certificates

Again won’t get into the guts (e.g. see here for details), but given its on-premise/hardware-centric approach, ADFS requires holes to be poked in the firewall and 3rd party certificates to be procured. Procuring certificates will probably take at least 4 hours of time and will require good knowledge of certificates and tokens, and of course getting holes poked in firewalls may take a lot of back-and-forth time with your firewall and security people, getting the appropriate approvals, etc. Again this can be quantified in many thousands of dollars of labor plus lost time to get your users productive using Office 365.

For cloud-centric organizations, waiting for security reviews/approvals to have holes poked in firewalls or acquiring certificates may be too cumbersome or take too much time. The Centrify Cloud Proxy Server takes 5 minutes to deploy and can be installed on existing Windows systems inside firewall with no firewall changes or need to acquire certificates, representing yet another cost savings and major differentiating capability.

So hopefully you get the differences vis a vis this:

Requires on-premises servers, licenses & support

There is a big difference between requirements in this area. But…you may say I have already invested in ADFS *OR* I can deal with a hardware-centric approach (vs. cloud-based approached), are there any more reasons to go with Centrify for Office 365? The answer is a big yes, which I will talk about some additional differences in my next blog post.