Each company has its own security policies and defines ways to access classified information. If we speak from security and technology point of view, a document can became unsecured as soon as is leaving the secured server where is stored. Encryption is indeed a good mechanism that allows classified information to be hosted for example on client devices (PC, notebook, tablet, smartphone …), but the classified information owner doesn’t have the same full control over the information as it has on the secured server.
That’s why the information is classified. One extreme is to simply block, or make as hard as possible to access the information, case in which the solution will not be adopted by the users and will be expensive to implement and maintain. The other extreme is to not enforce any kind of protection, or control, case in which the trust is lost.
The solution is somewhere in the middle – define ways to access classified information that prevents the majority of situations that can compromise / violate / cause damage.
I personally think specific level of classified information can be accessed on mobile devices and in the same time still have specific level of control over it.
Key technologies involved:
- Office Web Apps – is an Office server product that delivers browser-based versions of Word, PowerPoint, Excel, and OneNote. More details here and here.
- SharePoint – is a collaboration environment that organizations of all sizes can use to increase the efficiency of business processes. SharePoint 2013 sites provide secure environments that administrators can configure to provide personalized access to documents and other information. Search features enable users to find content efficiently regardless of the physical location of data. More details here and here.
- Active Directory Rights Management Services (AD RMS) – is an information protection technology that works with AD RMS–enabled applications to help safeguard digital information from unauthorized use. Content owners can define who can open, modify, print, forward, or take other actions with the information. More details here and here.
What’s New with Information Rights Management in SharePoint and SharePoint Online?
“Protected documents can be rendered in the browserAlso new to Office 2013, Office Web Apps can render protected documents. This means that if an authenticated user does not have a compatible Office client, they can still view the documents using Office Web Apps. Note that in the case of Web Apps, the document is presented in read-only mode. Also note that screen capturing of protected content in the browser is not blocked (as it is on clients), but, the information about the protected documents is cleared from the browser cache. Library admins can always prevent this capability by selecting the Prevent opening documents in the browser for this Document Library check box on the Information Right Management setting page (shown below in figure 5).”
Use Office Online on your Android, iPhone, or Windows Phone
“Thanks to the web browser in your cell phone, your phone can display online documents, using the mobile version of Office Online: Office Mobile Viewers. Office Mobile Viewers display Word, Excel, and PowerPoint documents that are stored online, or sent to your Microsoft email account as attachments. The documents are open for viewing only, not editing.”
IRM (Information Rights Management) features and limitations using Office Web Apps On-Premise
“Office Web Apps does not support the following features normally offered for non-IRM protected documents. These features are currently suppressed from the user interface:
- Edit in browser
- Save
- Copy selection
- Add comments”
Almost all the above links refers to official Microsoft sites where Office Web Apps is advertised as being mobile capable (render Office Documents in browser) and also capable to render protected documents.
SharePoint + Office Web Apps + AD RMS can be an ideal platform to allow viewing sensitive documents on mobile devices. I implemented this setup and I experienced some limitations. I also discovered some security holes (in my opinion), but found ways to bypass them.
The idea is simple:
- The documents stored on SharePoint are stored unencrypted. Basically the document is stored inside a MSSQL database, or Remote BLOB Storage. It is your IT department responsibility to secure the servers (MSSQL TDE, CipherPoint Eclipse for SharePoint, DocAve SharePoint Management …).
- In SharePoint you can configure IRM (Information Rights Management) that will help you to apply a specific policy for your files.
- AD RMS will encrypt all the download documents applying the IRM policy previously defined.
- For the SharePoint Document Libraries where an IRM policy is defines, the browser view of the Office documents is read-only and has couple of additional protection layers (prevents right click, print, …).
- The Office Web Apps Server can render in browser the office documents because in SharePoint the documents are stored unencrypted. That’s why is very important to secure (IPsec) also the communication channels between MSSQL, SharePoint servers, Office Web Apps.
- Obviously you need to implement TLS for SharePoint, Office Web Apps, MSSQL.
- The user will be able to view the sensitive document on his mobile device in browser. The user needs connectivity with the SharePoint farm + Office Web Apps server (ideally through VPN).
- If the user downloads the file, the document will be protected by AD RMS. At this moment (the date when this article was written) the Office Mobile version is not capable to decrypt Office documents protected by AD RMS. So, basically the user has on its mobile device a document who contains sensitive data, but the document is encrypted and unusable on mobile devices. If the document is transferred to a PC, MS Office will require connectivity with the AD RMS servers. If the connectivity and user authentication is not performed with the RMS server, then the content remains inaccessible.
- No browsing caching for the secured view. Basically a “clean” device, in case is lost, or stolen.
- Indeed, screen capturing of protected content in the browser is not blocked, but such restrictions can be applied using a mobile device management solution.
This setup is not “bullet proof”. The idea is to allow sensitive documents to be accessed from the mobile devices and in the same time apply some level of control and protection over the information delivered to those devices.
Indeed SharePoint + Office Web Apps + AD RMS are working almost as advertised in the above MS websites. I say almost because there are two things that bothers me.
1. The embed view does not work for the documents hosted by an IRM enabled document library.
This view is very useful because custom mobile apps can reuse this functionality (perfect for small screens). Microsoft is aware of this issue, but still no fix released.
2. The protection against copy & paste is available on the PC & tablet view of Office Web Apps for the IRM enabled document libraries, but is not available (copy and paste is possible) on the mobile view (smartphones).
Basically the look and feel is not consistent across devices. Protection against copy & paste is kind of necessary in this case, otherwise I don’t see a big difference in not protecting at all the documents. It’s again the “middle” scenario – you don’t block the access entirely, but for the majority of the users, preventing copy & paste represents some level of control over the classified information.
Next, I will reproduce the issue and also provide a way to bypass it (a workaround, not a fix).
I opened with Microsoft a support call [REG:114121212162050] and hopefully they will take it in consideration seriously – especially because this behavior is available also for the cloud version of SharePoint (SharePoint Online) and Office Web Apps (Office Online).
Example of PC view of Office Web Apps for the IRM enabled document libraries.
Example of tablet (iPad) view of Office Web Apps for the IRM enabled document libraries.
Example of smartphone (iPhone) view of Office Web Apps for the IRM enabled document libraries.
If we look carefully, we can notice the Microsoft Word Web App view is different from the one provided for PC, or tablet. That’s because indeed the view is different. This time the browser rendering points the smartphone directly to the Office Web Apps server (the protected-right-click-and-copy-paste SharePoint view is not involved anymore).
And because the Office Web Apps server is not aware of the IRM policy, it will simply provide the view for the mobile devices, same as a regular unprotected files (where copy and paste functionality is present)
The mobile user can copy the URL of the mobile view, paste it into an e-mail and access the link on PC.
Case in which the user was able to bypass the default protect view of Microsoft Word Web App (PC version).
Workaround
Attempt 1 – unsuccessful
Office Web Apps has the App_Browsers part of each mobile view. Unfortunately configuring the browser definition file doesn’t work for Office Web Apps.
http://technet.microsoft.com/en-us/library/ff393836(v=office.15).aspx
http://sharepoint.smayes.com/tag/compat-browser/
Attempt 2 – successful
On the Office Web Apps servers install URL Rewrite IIS extension and configure the server to “believe” all the request sent by the mobile devices (defined in the compat.browser) are in fact requests sent by tablets.
Office Web Apps is a HTTP based solution and is heavily relying on the IIS web server. The workaround is simple.
The in-browser view of Office Documents for PCs and tablets is in fact a SharePoint page with an IFRAME where the Office Web Apps response is displayed.
Office Web Apps server has a simplified view designed for mobile devices. When a user who’s using a smartphone connects on SharePoint and access for example a MS word document, he is accessing the same IFRAME’ed SharePoint page (as for PC and tablets), but this time the Office Web Apps response is “window.top.location.replace” who redirects the mobile device to the simplified view (the response is not trapped in the frame controlled by the SharePoint page). The problem now is the simplified mobile view doesn’t have any kind of copy & paste protection implemented for the IRM enabled document libraries.
The URL Rewrite module allows the web server administrators to control the userAgent string and change it as they wish. Office Web Apps server rely on the userAgent string to figure out what kind of response will provide (PC/Tablet or mobile view). So, basically if we are able to control the userAgent string, we are able to control the Office Web Apps behavior.
OK, but the PC/Tablet view is not optimized for small screens (mobile devices). This is true, is not optimized, but is also not looking that bad (see the bellow screenshots – iPhone 5).
The landscape view is quite close to how it looks on PC and tablet.
The portrait view is indeed not practical, but this time is the protected view (copy & paste not possible) and let’s not forget this is a workaround – provide the PC/tablet view (not optimized for small screens) to mobile devices.
How to configure IIS URL Rewrite to control the userAgent string?
1. You need to download and install IIS URL Rewrite module on the Office Web Apps server.
2. At the server level configure HTTP_USER_AGENT as managed server variable.
3. Add the following URL rewrite rule to the web.config located in C:\Program Files\Microsoft Office Web Apps\RootWebSite.
<system.webServer> <rewrite> <rules> <rule name="IsNotMobile" enabled="true" patternSyntax="ECMAScript" stopProcessing="true"> <match url=".*" /> <action type="None" logRewrittenUrl="true" /> <serverVariables> <set name="HTTP_USER_AGENT" value="Mozilla/5.0 (iPad; CPU OS 7_1_2 like Mac OS X) AppleWebKit/537.51.2 (KHTML, like Gecko) Version/7.0 Mobile/11D257 Safari/9537.53" /> </serverVariables> <conditions> <add input="{HTTP_USER_AGENT}" pattern="((iPhone)|(HTC)|(SAMSUNG)|([Ss]amsung)|(Nokia)|(BlackBerry)|(SymbianOS)|(Android)|(Mobile)|(Dolfin)|(Windows Phone)|(Windows CE)|(DoCoMo)|(FOMA)|(UP.Browser)|(SoftBank)|(MIB)|(KDDI)|(KYOCERA)|(T-Mobile Dash)|(KUN)|(S[0-9]*HT)|(NetFront)|(Mozilla/4.0 \(compatible; MSIE 6.0; Windows NT 5.1; T-01A\)))" /> </conditions> </rule> </rules> </rewrite> </system.webServer>
This URL rewrite rule is simply catching all the requests sent by mobile devices (where the HTTP_USER_AGENT string matches mobile devices) and replace it with another string (in my case the iPad userAgent string).
Based on my checks the output provided by Office Web Apps to iPad is generally compatible / can be rendered without problems on all the other mobile devices.