App Security
When delivering any technology solution
you must give special attention to the types of security measures that
have been taken to keep the user’s computer safe from malicious
attacks. As a developer, you need to have a good sense for what the
security framework is and the freedom and constraints with which you
have to work.
Figure 2
shows the security framework for Apps for Office. Your App for Office
actually runs in an Internet Explorer 9 or 10 Web Control out of
process from the Office client app itself, in a sandbox host process.
This provides a security boundary between your app and the client
application and also isolates your app if it should have performance
issues. The Office client application hosts the Web Extensibility
Framework Runtime, which is the broker that manages communication and
monitoring between the two processes, translates the JavaScript calls
to native ones, and remotely renders your App for Office in the client
application’s UI as a TaskPaneApp, ContentApp, or MailApp.
This security framework cannot be altered.
However, as the developer, you can declaratively request what level of
security permissions your app for Office needs to carry out its
business within the manifest file via the <Permissions>
element. You should be familiar enough with the API to set the
requested level of permission based on your API use. To use a part of
the API that requires more permissions than you’ve requested in the
manifest will result in the Office client blocking the use of that
specific part of the API at runtime. This, of course, results in an
error being thrown and most likely a frustrated user.
For document-based apps you can request the permission levels shown in Table 2.
The table intentionally represents gradations from least-privileged
permission to most-privileged permission as you move down the table,
where Restricted has the least permission on the document and ReadWriteDocument has the most.
TABLE 2: Document-based Permissions
∗ Source: Office manifest’s schema reference for apps on MSDN
| PERMISSION |
DESCRIPTION |
| Restricted |
Permission that applies to all TaskPaneApps, enables activation, and allows use of the Settings object |
| ReadDocument |
Includes the Restricted permission, and
also enables the TaskPaneApp to use the API to read the document,
manage bindings, and subscribe to events |
| ReadAllDocument |
Includes the Restricted and ReadDocument
permissions, and also enables the TaskPaneApp to use the API to obtain
a binary copy of the document |
| WriteDocument |
Includes the Restricted permission, and also enables the TaskPaneApp to use the setSelectedDataAsync API to write to the document |
| ReadWriteDocument |
Includes the ReadAllDocument and WriteDocument permissions, and also enables the TaskPaneApp to use all write APIs |
Table 3 shows the MailApp permissions. Note that if your MailApp requires the ReadWriteMailbox
permission, then an Exchange administrator must install the app. Apps
that require this permission level cannot be installed by the user.
TABLE 3: Mailbox-based Permissions
| PERMISSION |
DESCRIPTION |
| Restricted |
Permission that applies to all MailApps,
enables the ItemIs and ItemHasKnownEntity activation rules, enables use
of the RoamingSettings object, and is a subset of the app JavaScript
Object Model |
| ReadItem |
Applies to the selected item, includes
the Restricted permission, and enables the MailApp to use all the
well-known entities and regular expression activation rules to read all
properties and to write custom properties |
| ReadWriteMailbox |
Includes all the ReadItem permission and also enables the MailApp to use the makeEWSRequestAsync method to read and write all properties of any item in the user’s mailbox |
