How Do You Customize Your Policy?

As part of planning for our next release, we're interested in collecting some data on how you customize your security policy.  We're intereseted in as much information as you have to offer.  For instance, do you mainly add code groups to the machine level, or do you use the enterprise and user levels as well?  Generally are you just adding StrongNameMembershipConditions and PublisherMembershipConditions to grant higher trust to specific assemblies, or does your tinkering get more involved than that?  Is the main tool you use caspol, or do you use the .NET Framework Configuration tool in the Control Panel, or possibly even use your own tools?

Comments (8)

  1. Chris Overbeek says:

    Interesting question. We deploy custom assemblies from a webserver as objects in webpages, so our customers have to set a codegroup on the ‘client’ machines (any machine that will access the application) to grant trust to the URL our assemblies originate from (generally a machine setting, not enterprise or use). Since we have a visualization component that is only available as a COM/ActiveX control, we have to have full trust and we cannot sign our controls (our next release will remove that restriction, but we haven’t been able to determine minimum required rights for that release yet).

    We currently allow our customers to run a windows installer utility that installs the correct version of the framework if not present, installs our required pre-requisites (ADOMD.NET, VSTO, Primary Interop assemblies), and establishes trust with the correct server(s). Trust is configured using caspol in that case.

    We also allow them to deploy all of this through Active Directory using Group Policy, in which case they would create a package from the Framework configuration utility and deploy it along with these other packages.

    It works, but it is kind of ugly — especially if the client doesn’t already do any kind of GPO deployment in their enterprise.

  2. Thanks Chris. I take it from your comments that you basically exclusively use the UrlMembershipCondition to trust a site, and use caspol except for the case where you need to deploy your policy via group policy.


  3. Maxim Kortunov says:

    We are using .NET control in IE. For this to do we have strongly named our assembly. Then the XML file is used to import setting with .NET Framework Configuration tool. It is done manualy with a document describing the process. XML file is stored on a web server. So, we are using StrongNameMembershipCondition.

  4. Brant says:

    We are building VSTO applications and have taken the URLMembership approach. Deploying the applications has been a pain because of the security problems. What we have done is created a "Security Installer" that the customes run to setup the correct code policy.

    This installer also adds an entry to fix the "temporary assembly" problem that comes from the Xml serializer.

  5. chris seary says:

    We usually customise policy via a custom policy file for each application. It’s strange that there’s no GUI for this.

    For Windows, it’s mainly done using caspol.

    The Framework Configuration Wizard is useful for viewing settings, but as it doesn’t refresh it’s not really the best tool to work with.

  6. We use custom policies for our applications. This pilicy will be created using the cas security api and deployed using a custom installer package that is signed with our certficate.

    What I really miss is a kind of wizard that presents developers common scenarios (eg. loading from a network share, using strong named 3rd party components and then creates an msi package automatically based on the selected scenario.

    With clickonce the permissions page in the vs ide is still too complicated to use for a vb6 developer 😉 The result is loads of apps that still run will full trust.

  7. chris seary says:

    Do we get to put forward a wish list?

    How about a version of caspol and the gui that will work with ASP.Net CAS files. That’d be top banana.

  8. Chris Overbeek says:

    Sorry, never checked back to this thread.

    In answer to your question, yes we use the URL condition almost exclusively, as http is the mechanism for deployment, and with full-trust grant, we want to control the scope as tightly as possible without requiring lots of manual steps.

Skip to main content