Hosting Office365 Content In An iFrame Results In A Non-Seamless SSO Experience

We are used to media rich experiences when dealing with web sites and applications, and expect a seamless experience across our services.  The new rich features in Office365 make hosting some content in a hybrid architecture initially very attractive.  And while these architectures can deliver on their promises, successful deployments require some forethought and planning. Initially, many administrators think to themselves that the process is relatively simple and straightforward.  Utilizing the embed code offered on certain products, such as Microsoft Stream videos, they house that code locally and expect a seamless experience.  They may even test it, and see that everything is working as they imagined.  However, when these features are released to users, the feedback that users receive is that the experience is not truly seamless and that they are prompted to log in.  Often, this results in them opening a support case. 

So what went wrong? Why did our admin see the seamless experience, but his user not? While the technical explanation on what exactly occurred here is discussed below, the short answer on why we have this behavior in the first place has to do with a kind of malicious attack known as “Clickjacking.”  

What is ClickJacking? 

Clickjacking is a term coined in 2008 to describe a type of attack where authentic content is presented to the user in a way that allows a malicious actor to hijack that content in a manner than the user does not consent to.  For example, an authentication prompt inside an iFrame could be used to harvest the user’s credentials to the service simply by presenting the prompt and reading the inputs from the user.  For those looking for further information, a technical deep dive on the subject of Clickjacking can be found on Wikipedia. 

When a user requests a resource hosted in SharePoint Online, they present an authentication token to the service at the time of the request.  Requests that do not have this token are redirected to authenticate to the service.  When the resource request originates from within an iFrame, we detect that and prompt the user to click to authenticate, spawning a new window outside of the iFrame and thus no longer subject to any malicious code that exists elsewhere on the page that we do not control.  This prevents the user from potentially entering in their credentials in a compromising manner, and maintains the confidentiality of the credential set.   

Why does the Admin not get prompted?

The central problem with the need to click to login is not the iFrame, but the lack of authentication tokens.  Our Admin was authenticated to the service to get the embed code in the first place.  When he inserts the code into the web page, he still has his authentication tokens to the Office 365 service, so the testing is done in the context of an authenticated user.  To the admin, the experience appears seamless. 

However, in situations such as above, with a hybrid infrastructure where most web content is hosted on premise, and video hosted in Office365, there is a reasonable expectation that users are not interfacing with Office365 in a regular way. It is only after a reasonable number are consuming web based services that the experience becomes truly seamless.  Otherwise, users who do not consume Office365 services except through embedded iframes will continue to be prompted to authenticate before loading the content.

Comments

• Anonymous
  December 09, 2017
  Pretty useful to read this blog post.