So we must be talking about Identity Management. Nope.
In this case we are talking about federating calendars between on-premises and cloud services such as Outlook Live and Exchange Online (when our back-end moves to Exchange 2010). This can also be used to share calendars between your school and partners to shared their availability information (free/busy) for scheduling meetings.
In previous editions of Exchange we had to use tools like the inter-org replication tool to provide this type of integration as well as Active Directory Trust in both ways which most times has been undesirable with 3rd parties or even within school systems.
In Ex2007 we were able to change the entire model from system folder (free/busy) to looking at experiences with Exchange Web Services (EWS), availability Services, and the Client Access Server (CAS). So to configure availability services between forest you could do this:
Add-AvailabilityAddressSpace -ForestName "contoso.edu" -AccessMethod PerUserFB -UseServiceAccount $true
More info on this can be found here.
So now we jump to light speed and we now have “Federated Sharing”. So yes it’s federated but no it’s not identity management. This now allows use to enable users to share information with recipients with external federated organizations such as (Outlook Live, Exchange Online). Federating Sharing uses the Microsoft Federation Gateway (MFG), as the trust broker between two federated organizations.
Notes: Exchange Server 2010 uses Microsoft Federation Gateway (MFG), an identity service that runs in the cloud, as the trust broker. The trust allows users authenticated by Active Directory , known as the identity provider (IP), to be issued Security Assertion Markup Language (SAML) delegation tokens by MFG. The delegation tokens allow users from one federated organization to be trusted by another federated organization. With MFG acting as the trust broker, organizations are not required to establish multiple individual trust relationships with other organizations.
The requirements for this with Outlook Live and Exchange Online are the following:
STEP 1 – Setting up Federation
To setup federation sharing the customer is required to use a public cert with these requirements for integration with the MFG.
Since the certificate is not used for authentication, it does not have any subject name or subject alternative name requirements. You can use a certificate with a subject name that is the same name as the hostname, the domain name, or any other name. Only one certificate is required for the Federation Trust. Exchange automatically distributes the certificate to other Exchange 2010 servers in the organization.
Now that we have a cert I’ll talk about configuration with gateway in Part II.
technet.microsoft.com/.../dd335047.aspx indicates that a self-signed certificate is valid:
Certificate Requirements for Federation
To establish a federation trust with the Microsoft Federation Gateway, either a self-signed certificate or an X.509 certificate signed by a certification authority (CA) must be created and installed on the Exchange 2010 server used to create the trust
Can you clarify?