Using smart links or IdP initiated authentication with Office 365

What is a smart link?

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:

Encodes where any SAML token issued by the AD FS 2.0 server needs to be posted (i.e. to the Office 365 identity platform)

Encodes the relying party service that the user was trying to reach (like the URL for Exchange Online or the Office 365 portal)

This URL is commonly termed a smart link or also an identity provider initiated sign in link.

Why should I care about smart links?

Organizations can deploy smart links internally (by creating a vanity URL that maps to the smart link) that provide:

An easier to remember vanity URL for your organization's users to use when going to Office 365 services, reducing support calls to your IT helpdesk. These vanity URLs can also be written to user's IE favorites as part of a global policy setting.

An improved end user experience when accessing Office 365 services, which increases end user customer satisfaction:

Faster authentication to the Office 365 service (two fewer redirects)

Users will not have to go through the home realm discovery service

This post describes how an organization can create and deploy smart links for their users.

How to deploy smart links for my organization

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.

Creating a smart link

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.

You'll need to edit this by removing everything up to the "wa" querystring parameter, remove the last QS parameter "bk", and remove the "ct" parameter (up to the 'ver' parameter). See "For reference: Smart Link URL template" for more details on the format of the smart link.

Your edited URL forms the smart link that you will use to create a vanity URL for users to reach the Office 365 portal in the most seamless single sign on fashion, by following the steps in "Deploying a smart link".

Deploying and verifying the smart link

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.

Create a new A record in your domain registrar (like portal.contoso.com) and point this to the IP address of your IIS server that will host your redirection service

Create a new web site (portal.contoso.com) on your IIS server

Create a 302 redirection service, and paste the smart link into the target address

Query-string Parameter Semantics

Parameter

Description

wa=wsignin1.0

Indicates that the request is for sign-in.

wtrealm= urn:federation:MicrosoftOnline

Indicates that the token is requested by the Office 365 identity system.

Wctx

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".

[1] 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.