The term Federation is something I am familiar with, thanks largely to may hours spent watching Star Trek as a kid. The United Federation of Planets in the TV series/movies referred to very different cultures having a common bond, in a political sense. Federation when it comes to cloud services has more than one meaning, and I want to use this blog to explain the term Federation and how it relates to various cloud services and how it improves the overall cloud experience.
We will talk about federation relating to cloud services hosted by Microsoft specifically Office 365, although Windows Intune and Azure also use the term Federation (ill save those for a future blog post). There are many other technologies that deliver similar results with other cloud services but I really want to focus on the term federation when it relates specifically to a Microsoft solution.
In the old days of Windows NT if you wanted to access information in another Domain you would need to setup a trust , a trust was setup either one way or two way and was generally quite unreliable. It did however address the issue of sharing information between business units or organizations (if you were brave). There needed to be a better more secure way of sharing information while limiting the access either party had to the other party’s security context.
Along came Active Directory Federation Services or ADFS, it has been around for some time and uses Microsoft’s version of the Security Assertion Markup Language or SAML claims based authentication model. It is now in its second generation and with version 2.0 comes the ability to federate your Active Directory with Office 365. ADFS 2.0 isn’t just restricted to Office 365 for its federation options, there are a number of cloud providers that support ADFS including IBM Tivoli, Novell Access manager, Sun Open SSO and CA (Site Minder and Federation Manager) using SAML, Microsoft is also a founding member of OpenID the organisation that is promoting standards in identity management.
ADFS 2.0 allows a customer to federate their identity to the cloud services contained within Office 365, creating what is known as a Single Sign On experience for end users. Single Sign On or SSO allows users to login to their PCs (assuming they are connected to an Active Directory service with ADFS installed) and seamlessly connect to any Online Service they are licensed for and have permission to access. SSO is the holy grail of any cloud service and removes one of the biggest barriers to cloud adoption in the enterprise.
ADFS is a pre-requisite when you want to configure Exchange or Lync (Lync will allow this in a future release) to run in a hybrid scenario (what used to be called co-existence). For more information on running a hybrid deployment of Exchange 2010 SP2 go here: http://technet.microsoft.com/en-us/library/gg577584.aspx
Due to its complexity and demand on resources (servers and administration) ADFS is only suited to larger organizations, thus ADFS implementations are only possible with the Enterprise offering of Office 365 (E and K plans). ADFS also requires an additional Windows Sever 2008 (or R2) and some thought into providing a resilient installation (read more than one ADFS server!), if the ADFS service fails… users will no longer be able to connect to their cloud services either from inside their network or externally.
To learn more about ADFS go here : http://technet.microsoft.com/en-us/library/cc736690(v=ws.10).aspx
For a tutorial video on identity and Office 365 go here: http://technet.microsoft.com/en-us/edge/office-365-jump-start-04-microsoft-office-365-identity-and-access-solutions
Virtual Labs on ADFS and Federation here: http://technet.microsoft.com/en-us/office365/hh744605
Given the complex nature of setting up a resilient ADFS service there needs to be another way to synchronize user accounts from an on-premise Active Directory to the cloud. The previous version of Microsoft Online Services (Business Productivity Online Services) or BPOS attempted to make life easier for administrators by providing a one-way sync from the on premise Active Directory Server to the cloud. This sync known as DirSync would create the user ID’s in the cloud (over writing whatever was there to begin with), the one major problem was that it didn’t synchronize the users Passwords. This option is still available to all users of Office 365 and doesn’t require the complexity associated with ADFS, it will however only synchronize objects from the on-premise AD to the cloud, including groups and users. The DirSync application has been updated to include a x64 version that in turn must be installed on a members server (non-domain controller). From the admin portal under users you are able to setup the DirSync function.
To learn more about DirSync go here: http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff652543.aspx
Application Specific Federation
Now that we have covered the use of Federation when it relates to your user identity its nice to know that the word Federation is also used when describing the sharing of information between applications existing in separate organizations.
Lync Online delivers its Federation experience by putting you in touch with those who are not part of your organization. It has the ability to federate presence, instant messaging and voice/video calls with the following deployments:
- On-premise Office Communications Server 2007 R2
- On-premise Lync Server
- MSN (Live) Messenger
- Other Office 365 customers
Obviously the other organizations will need to have federation setup themselves. For your Office 365 deployment it is as easy as ensuring the SRV record is configured in your DNS settings as described previously here and the federation is enabled in your Office 365 administration portal / Lync Online Control Panel as pictured below.
There is a tool which searches you contacts for those who are available to federate via Lync here: http://gallery.technet.microsoft.com/Who-Can-Federate-Tool-a9e00d23 There is also a database maintained of the organizations with either OCS 2007 R2 or Lync on-premise / Online who are available for federation available here: http://www.lyncdirectory.com/
Federation relating to Microsoft Exchange is a one-to-one relationship between two federated Exchange organizations that allows recipients to share free/busy (calendar availability) information. It is also known by the term “federated delegation“. Both sides of the Federation need to be configured, for an on-premise Exchange 2010 deployment a connection must be made to the Microsoft Federation Gateway. The Microsoft Federation Gateway provides applications with a free, simple, standards-based method of establishing trust between separate organizations that uses SSL certificates to prove domain ownership. Because the organizations federate with the gateway instead of with each other, it is much easier for an organization to establish trust relationships with multiple partners than is possible when it uses conventional one-on-one federation or other trust relationships. The scope of the federation can be easily controlled by creating allow or deny lists of users and domains for licensing and by specifying the domains that can receive publishing licenses. This guarantees that only appropriate organizations are given access to protected information. More information for a local deployment of Exchange 2010 can be found here: http://technet.microsoft.com/en-us/library/dd335047.aspx or here http://technet.microsoft.com/en-us/library/dd638083.aspx .
With Office 365 the hard work is done for you. All of the detail described above is baked right in and it is up to the users to delegate the access to their own calendars individually. This is turned off by default and can be enabled to the following degree:
- No free/busy access
- Free/busy access with time only
- Free/busy access with time, plus subject and location
This access can be granted via the Outlook application and can be granted to users outside the organization if they are using a Federated Exchange Server or another Office 365 tenant. There is a tool that will tell which one of your contacts is available to view you calendar available to download here: http://gallery.technet.microsoft.com/Exchange-Federation-fdf8a324
Although not strictly Federation at the application level, it utilizes Federation between the Office 365 tenant and Windows Live ID’s. Within any deployment of Office 365 and Sharepoint Online you are able to invite external users to view or edit your documents by simply sharing the site/library and use their email address. If the recipient hasn’t done so already they will be prompted to create a Live ID when they attempt to access your site using their email address. This external access is included in Sharepoint Online within Office 365 and doesn’t consume any licenses. Keep in mind as I mentioned previously that the P plan of Sharepoint Online does NOT deliver the content over a secure channel (SSL) so you should ensure you choose the right plan for your intention.
Federation is a term that will be used hand in hand with any cloud conversation in the future. As with any technology it pays to understand it ahead of time and ensure your customers/users are using it in an appropriate manner.
#1 by Loryan Strant (@TheCloudMouth) on April 21, 2012 - 8:04 pm
Great article Nick, clear yet thorough overview of federation.
Just a couple of points:
– Lync Online doesn’t support AOL (even though Lync Server on-premise does)
– Lync Online doesn’t support hybrid / co-existence with Lync Server (aka “split domain”) at this time
#2 by Nick Bowyer on April 21, 2012 - 8:31 pm
Thanks for the feedback – updated the article. I am aware that Lync on premise hybrid deployment will be available soon? Also the future may certainly allow for federation of Skype with Lync due to the recent change of ownership…