Sign up for Office 365
Learn more about Office 365
Traditionally when a customer sets up single sign-on (identity federation) to Office 365, the authentication mechanism used for web browser applications uses the WS-federation passive profile. More details on this mechanism can be found in the blog post "How identity federation works". Core to this mechanism is a process called "home realm discovery", whereby the end user needs to provide information to the Office 365 login server, so that the login server can determine if it should authenticate the user, or redirect the user to the on-premise identity provider (the authoritative authentication provider) for that user. In the federation case, this redirect constructs a URL that:
This URL is commonly termed a smart link or also an identity provider initiated sign in link.
Organizations can deploy smart links internally (by creating a vanity URL that maps to the smart link) that provide:
This post describes how an organization can create and deploy smart links for their users.
Once you understand how to construct a smart link for the target Office 365 service, you can deploy a 302 redirection service on your on-premise web servers. This assumes that you have already set up Single Sign-On (Identity Federation) for Office 365 and have verified that it is working correctly.
The simplest way to create a smart link is to turn on an HTTP tracing tool and authenticate to the desired service. In the future, Office 365 may provide a service for administrators to that automatically constructs the smart link. Until that time, please follow the manual instructions below.
Once you've created your smart link, you'll need to deploy it by creating a vanity URL for your organization's users to use. In the example above we created a smart link for the Office 365 portal (https://portal.microsoftonline.com/). Now we'll create a vanity URL that will redirect (302) to the smart link above.
This is your ADFS passive endpoint URL. It's normally something like https://<your_AD_FS_2.0_Server_public_URL>/adfs/ls. For example: https://sts.contoso.com/adfs/ls.
Indicates that the request is for sign-in.
Indicates that the token is requested by the Office 365 identity system.
This value must be returned with the authentication token that is issued by the AD FS 2.0 server. Typically the wctx parameter contains information relevant to the resource that the user is trying to access.
Creating the value for the Wctx parameter is non-trivial, which is why it is recommended that you use the approach described in "Creating a smart link".
 We're using a 302 redirection service rather than a DNS CNAME record, because otherwise the user will get a certificate pop-up that the site requested does not match the name on the certificate of the site visited.