Information workers frequently need to collaborate with external recipients such as vendors, partners, and customers, and share their availability (free/busy) information, calendar, or contacts. So we speak about
1. Federated free/busy sharing
Access free/busy information of an external user in a partner’s company. The published Exchange availability service of the partner’s company answers directly using the requested information from user’s mailbox. No public system folder is used anymore.
2. Federated calendar sharing
Access calendar information of an external user in a partner’s company. The user has to ask the external user to share his calendar by using the features of Outlook or Outlook Web App.
3. Federated contact sharing
Access private contacts information of an external user in a partner’s company. The user has to ask the external user before to share his contacts by using the features of Outlook or Outlook Web App.
In this second part I will give a technical level overview about what Microsoft Exchange Server 2010 Federation services provide and what the limitations are.
How Federated Sharing technically works
Have a valid public certificate present. Note:Microsoft accepts for Federation only a few Certificate Authorities.
Publish Port 443 (https) for the client access server to the Internet
The source organization establishes a federation trust between its Exchange 2010 organization and the Microsoft Federation Gateway. The target organization does the same. By exchanging the organization’s certificates with the Microsoft Federation Gateway, every company retrieves the Microsoft Federation Gateway certificate and federation metadata. Microsoft Federation Gateway acting as the trust broker, an identity service that runs in the cloud.
An additional DNS entry is required at each side.
The Usage of the Microsoft broker service is cost-free. Building up an own Federation Gateway is recently not possible.
For a detailed technical description how to configure federation see part III of this blog.
How free/busy sharing works in detail
1. The user makes an free/busy request and insert the smtp-address of the other company’s person in Outlook 2010 or Outlook Web App. This address is not shown in its own companies GAL – he has to know it.
2. The Client Access Service of his own organization then looks up to Active Directory and discovers that for this target domain is a federation configured. CAS gets the Endpoint information about the partner’s organization.
3. The CAS Server now requests a token from Microsoft’s Federation Gateway which validates that the sender’s organization is trusted by the target organization. MFG signs the token and encrypts it with the public key of the target organization.
4. The token has to be received newly every time a user makes a new request. It is not stored on the client side.
5. The token received from MFG is specific for the requesting user and the target organization. That means it is only for this purpose and must be requested again at the next free/busy request.
6. The token is received by the source CAS server and then the free/busy request is is sent to the CAS Server of the other company’s published web service.
7. After receiving the token the CAS Server at the partner’s side validates if the senders organization is in his trust list. Further on the CAS server validates if free/busy sharing is configured at organizational or users level. If all policy validations are checked the availability service gets the requested information from the users mailbox and the answer is sent back to the client.
8. All communication is encrypted. Data are stored neither in the cloud nor in the requesting organization. It is really an “online” access.
Calendar sharing is a bit different from free/busy sharing.
1. You also need a federation trust to authorize the requesting user, but the requests are made directly to the external user.
2. After receiving a sharing invitation the external user shares it’s calendar in the same way it shares it to internal users.
3. In the user’s mailbox a subscription folder is created and all new calendar information of the external users are pulled into this calendar subscription folder. When the requesting person now views the calendar all information from the external calendar is updated by a server-side mechanism, using the federation token to ask on behalf of the requesting user the calendar data of the external user.
4. Both users have to run Outlook 2010 or OWA 2010.
For this a GAL sync of the user objects is not required. The external user has not to be in GAL of the “publishing” user’s organization.
Contact sharing works like Calendar sharing based on central federation, an users sharing invitation and an receiver’s sharing.
Security and Policies
The administrator can restrict access to calendars and contacts centrally by configuring policies. These policies might be more restrictive as the user itself has configured.
1. If your organization uses Exchange 2007 you have to install at least one Exchange 2010 CAS server to act as a proxy accessing the other organization. All Exchange 2007 servers require Service Pack 2. All users’ requests are handled by the Exchange 2010 CAS server.
2. If you use Outlook 2007 your organization still needs the user objects of the partners organization replicated to your Active Directory, because there is no way to access the GAL of the partners organization directly.
1. TechNet Webcast: Calendar Sharing and Federation in Microsoft Exchange Server 2010 (Level 300)
2. Exchange 2010 Federation Part I-III