The passphrase is "Install already": A new look at VSTO Security.
I've tried to start this post about ten times now, and honestly, the problem is that it's a little hard to know where to start. So I'm just going to dive in.
With VSTO 2.0 to "trust" your customization, you would have to create Caspol entries for everything, including (I believe) the location of the document if it was a customized document. Additionally, there was this Click Once deployment thing that used the Internet explorer cache.
VSTO 3.0 on the other hand has a completely totally different outlook on things. (Groans for the play on words are expected)
So let's first talk about what VSTO 3.0 doesn't use.
First off: we no longer use Caspol. You could create trust entry for everything in your solution, but it's not going to help your solution run. Secondly, the Click Once deployment we use is not the same Click Once that was In VSTO 2.0. We've redesigned the whole Click Once experience in VSTO 3.0 to be much more consistent with the Windows Forms Application Click Once. We no longer force you the developer to create custom windows installers just to install your customization on another machine.
That said, here's what VSTO 3.0 is:
So the new Security in VSTO 3.0 is (almost completely) the same if you are installing using Click Once, simply F5'ing a solution or if you create a Custom installer using a technology like Windows Installer. The differences between these 3 scenarios are details that I'll leave for another day because each of them is a large enough topic to be a post in of itself.
The core of the security model comes down to some basic ideas.
Every part of a program (customization in this case) are not individual units but rather just part of the greater whole. If you can maintain a "signature" that identifies and seals all of the parts of the program so that any tampering is easily detected, this single trust action is enough to ensure that all the parts themselves are trusted.
You can trust (or not trust) either the developer of a program, or you can trust just the program itself if you don't want to trust all programs of the developer.
With those 2 simple concepts we get the basic VSTO security model. In our model we actually take advantage of the security model Click Once gives us, and some of our own parts. We use this combined model even when we are not using Click Once to install the solution. It may seem a little strange at first because usually when people talk about Click Once they are talking about things like "automatic updating", special manifests and the Click Once Cache.
There's also a very rich security model in there. We take advantage of this model and add a few more things, this lead us to:
The actual VSTO 3.0 Security model (I feel like I've already ran the 10 miles but only started the race).
Our model consists of 3 or 4 basic types of objects.
The first type is the "document", it's only valid for document level customization (and really could be a document file, a workbook, or a template). Both Word and Excel require that any customization attached to a "document" can only run if the "document" is trusted. We can make this decision based on 2 things: Location and the Office Trusted Locations List. If the document is local (but not in a specific set of temporary locations) it is trusted. If the document is on a network, the location it is stored at must be in the Office Trusted Locations List.
The second type of object is the deployment manifest. In VSTO 2.0, manifests we optional, this is no longer the case. Your customization will have a deployment manifest, when you build you can find it as a .vsto file. The deployment manifest describes the type of deployment of the solution. Part of this information is some basic details about the certificate used to sign the solution, specifically the publisher and the signature authority can be determined based on this information. Trust decisions are ultimately based on the information contained within the deployment manifest. This file is signed with the developers signature (using the signing certificate), and as such will automatically fail a security check if the file has been changed. The deployment manifest points to the application manifest.
The third type of object, the application manifest (the .dll.manifest file) describes the what the application is. It includes all binaries and resources that will be installed into the Click Once Cache, should the solution be installed. Part of the information about each of the files in the solution is the hash of that file. The application manifest is also signed, which means, once it is signed, any of the solution files being altered will cause it to no longer be valid (Additionally, changing it's contents changes the signature and it will not install without being re-signed).
The final type of object is the application files. These range from dlls to resource files, basically anything that is part of your customization that you expect to install into the Click-Once Cache.
Except for the document type of object, trust for the other parts comes down to one of 2 options:
Trusting the publisher (developer) or Trusting the customization.
A publisher is "Trusted" only if the developer's signing certificate is in the users trusted publishers certificate store and the Certificate Authority that issued the certificate to the developer is a Trusted Root Authority or "chains" to one.
A publisher may be "Known" (verifiable identified) if their certificate comes from a Trusted Root Authority. I expect in most enterprise shops, the enterprise will enforce trusting of a specific publisher. I expect most small home/business developers will only have "known" certificates from a Certificate Authority like VeriSign. A "Known" certificate grants a certain amount of trust-ability to a customization ex: If it's a known certificate a trust prompt will be allowed by default when the solution is installed from the Internet, but it does not actually make the solution trusted (I'll talk more about this when I talk about the inclusion list).
A publisher can also be "Un-Trusted", in which case a customization signed by their certificate will never install.
If the publisher isn't "Trusted", it may be possible to trust the solution (given it is not "Un-Trusted"). If the solution is published in the Internet zone (ex: not on a local intra-net or not on a local drive) it (by default) must be signed by a "Known" publisher. If the solution is on a local intra-net or HDD location then an "unknown" certificate will suffice, but it also brings with it much smaller degree of "trust-ability". In either case, the next step is to trust the solution. We can make a local trust decision for a solution that involves the location it is in and the public key of the certificate used to sign the manifests. There are 2 entry points for these decisions to be made: and API that can be accessed (the inclusion list API) via the Microsoft.VisualStudio.Tools.Office.Security namespace or by clicking the "Trust Prompt" that will come up during installation. Clicking the "Trust Prompt" will actually create an inclusion list entry. When that entry is created, the solution goes form "Not-Trusted" (Trust or Un-Trust has not been determined) to Trusted. The prompt includes a "don't install" option which effectively says "I don't trust this solution".
Hopefully that explanation isn't too confusing, as you can see though, it is a little complicated (and this is the simplified version).
The good news is, what the developer has to do to make their solution work isn't all that bad.
Ideally, obtaining a certificate from a globaly acknowledge Certificate Authority (or from an internal Certificate authority if the solution is for an internal solution only) is the first step.
Sign the manifests (dlls are not required to be signed, but signing them should not cause problems) using the Signing properties page in Visual Studio.
Publish (or distribute) the solution to it's appropriate location.
Let the users or user's IT administration handle determining trust (either via the trust prompt, or via trusting the developer certificate).
In the next installment, I plan to go into depth the inclusion list and all of the curious factors that can come into play.
Thank You for reading.
Kris