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[1]) to the smart link above.
[AD_FS_2.0_WebLoginURL]?wa=wsignin1.0&wtrealm=urn:federation:MicrosoftOnline&wctx=[Custom_Value]
Value
Description
AD_FS_2.0_WebLoginURL
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.
Parameter
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.
4 out of 5 people found this post helpful.
Please add how to enable HTTP Tracing in Internet Explorer to the directions.
There seems to be an issue with the FedAuth cookie getting installed if you use the SmartLink redirection method. Is there a defined reason why this methodology does not install the FedAuth cookie?
In the case that I have the users have mapped drives and/or network locations to SHarePoint libraries. If the cookie is present then the connection to the library works. But if you use the smart link method as described in this post the FedAuth is not installed and the mapped drives/network locations to the SharePoint libraries breaks.
@Skytech: We are also experiencing this.. we implemented Smartlinks and certificate based authentication on the STS for a seamless initial login. But the issue is when folks try to open an Office document in Sharepoint there is no cookie, so they have to type in their username again. Looking at options but am thinking it will have to be a WIF application from the ground up to do this.
Let me know if you've come up with anything else and I will update as I find more information.
Wouldn't it be more straightforward for MS to make a minor tweak to portal.microsoftonline.com to make it able to accept a username parameter?
So opening portal.microsoftonline.com just does the usual home realm discovery on foobar@contoso.com without user intervention, and redirects to contoso.com's ADFS farm?
That should have read:
So opening portal.microsoftonline.com?username=foobar@contoso.com just does the usual home realm discovery on foobar@contoso.com without user intervention, and redirects to contoso.com's ADFS farm?