Recently we had a requirement from a customer who has ADFS deployed and they wanted to make the sign on experience easier for users. Currently when a domain joined user tries to access an Office 365 resource like http://portal.office.com they would still have to type or select their account and then they would be signed on. The customer wanted to make this experience more seamless for users.
The solution was to deploy a smart link.
Using smart links or IdP initiated authentication with 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. 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:
- Sends the browser to the authoritative AD FS server passive login endpoint
- Encodes where any SAML token issued by the AD FS 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.
The smart link has the following format – “https://sts.contoso.com/adfs/ls/?wa=wsignin1.0&wtrealm=urn:federation:MicrosoftOnline&wctx=MEST%3D0%26LoginOptions%3D2%26wa%3Dwsignin1.0%26rpsnv%3D2%26ver%3D6.1.6206.0%26wp%3DMCMBI%26wreply%3Dhttps:%252F%252Fportal.microsoftonline.com%252FDefault.aspx%26lc%3D1033%26id%3D271345”
You can capture the URL that is used using a tool such as Fiddler when you attempt to sign in you can capture the correct URL, in this case its the 302 redirect session.
Remove everything between ‘…/adfs/ls/?‘ and ‘wa=wsignin…‘, and everything after ‘…wreply%3D‘. The string now looks like: “https://federation.domain.com.au/adfs/ls/?wa=wsignin1.0&wtrealm=urn:federation:Microsoft Online&wctx=MEST%3D0%26LoginOptions%3D1%26wa%3Dwsignin1%252E0%26rpsnv%3D2 %26ct%3D1348618157%26rver%3D6%252E1%252E6206%252E0%26wp%3DMBI%26wreply%3D”
You now have the basis of a smart link that when used on a domain joined computer will take the user directly to the Office 365 Portal, you can also extend this to other parts of Office 365 such as SharePoint Online. e.g.
To deploy your new smart link
- 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
- Test that portal.contoso.com resolves to the correct IP address inside and outside your corporate network.
- Open IE and type http://portal.contoso.com/ and you should get seamless single sign-on directly to the Office 365 portal.
Having trouble implementing this or want to ask a question? Leave a comment or give us a call.