I have an application that has been deployed at a client site where it
runs under a strong-named security context (it lives on the LAN – is
not installed on each machine, thus all assemblies must be signed and
added to a code group on each client machine's runtime security
policy).

I now want to deploy an upgrade that uses a third-party component not
used in the first deployment. I expect to have to add a new
code-group to the runtime security policy on each client machine so
the assembly can be called by my app.

I was wondering if there was any way that the referenced assembly's
public key is somehow pre-approved in the main assembly's manifest so
only the main assembly's public key needs to be known by the
framework. It would greatly simplify deployment where many
third-party components each have a different public key.

Hi Rodney,

There is no way to "pre-approve" a public key, however you could do one of two things. Since your app is already trusted, you could
programatically modify the security policy to include the third party's public key at startup. You could also Assert for the trust that the 3rd party
needs (with the standard disclamers about being very careful with asserts applying). Feel free to post back if you need details on either of these
methods.

-Shawn
http://blogs.msdn.com/shawnfa

--

This posting is provided "AS IS" with no warranties, and confers no rights.
Note: For the benefit of the community-at-large, all responses to this message are best directed to the newsgroup/thread from which they
originated.
--------------------
>From: (E-Mail Removed) (Rodney)
>Newsgroups: microsoft.public.dotnet.framework
>Subject: Avoiding adding another code group
>Date: 26 Jan 2004 13:59:02 -0800
>Organization: http://groups.google.com
>Lines: 16
>Message-ID: <(E-Mail Removed)>
>NNTP-Posting-Host: 218.101.103.178
>Content-Type: text/plain; charset=ISO-8859-1
>Content-Transfer-Encoding: 8bit
>X-Trace: posting.google.com 1075154342 32436 127.0.0.1 (26 Jan 2004 21:59:02 GMT)
>X-Complaints-To: groups-(E-Mail Removed)
>NNTP-Posting-Date: Mon, 26 Jan 2004 21:59:02 +0000 (UTC)
>Path: cpmsftngxa07.phx.gbl!cpmsftngxa10.phx.gbl!TK2MSFTNGXA05.phx.gbl!TK2MSFTNGP08.phx.gbl!newsfeed00.sul.t-online.de!t-online.de!
news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!postnews1.google.com!not-for-mail
>Xref: cpmsftngxa07.phx.gbl microsoft.public.dotnet.framework:63604
>X-Tomcat-NG: microsoft.public.dotnet.framework
>
>I have an application that has been deployed at a client site where it
>runs under a strong-named security context (it lives on the LAN – is
>not installed on each machine, thus all assemblies must be signed and
>added to a code group on each client machine's runtime security
>policy).
>
>I now want to deploy an upgrade that uses a third-party component not
>used in the first deployment. I expect to have to add a new
>code-group to the runtime security policy on each client machine so
>the assembly can be called by my app.
>
>I was wondering if there was any way that the referenced assembly's
>public key is somehow pre-approved in the main assembly's manifest so
>only the main assembly's public key needs to be known by the
>framework. It would greatly simplify deployment where many
>third-party components each have a different public key.
>

Thanks Shawn - I am not familiar with either of these methods, could
you please give more information.
Many thanks,
Rodney.


(E-Mail Removed) ("Shawn Farkas") wrote in message news:<(E-Mail Removed)>...
> Hi Rodney,
>
> There is no way to "pre-approve" a public key, however you could do one of two things. Since your app is already trusted, you could
> programatically modify the security policy to include the third party's public key at startup. You could also Assert for the trust that the 3rd party
> needs (with the standard disclamers about being very careful with asserts applying). Feel free to post back if you need details on either of these
> methods.
>
> -Shawn
> http://blogs.msdn.com/shawnfa
>
> --
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
> Note: For the benefit of the community-at-large, all responses to this message are best directed to the newsgroup/thread from which they
> originated.
> --------------------
> >From: (E-Mail Removed) (Rodney)
> >Newsgroups: microsoft.public.dotnet.framework
> >Subject: Avoiding adding another code group
> >Date: 26 Jan 2004 13:59:02 -0800
> >
> >I have an application that has been deployed at a client site where it
> >runs under a strong-named security context (it lives on the LAN ? is
> >not installed on each machine, thus all assemblies must be signed and
> >added to a code group on each client machine's runtime security
> >policy).
> >
> >I now want to deploy an upgrade that uses a third-party component not
> >used in the first deployment. I expect to have to add a new
> >code-group to the runtime security policy on each client machine so
> >the assembly can be called by my app.
> >
> >I was wondering if there was any way that the referenced assembly's
> >public key is somehow pre-approved in the main assembly's manifest so
> >only the main assembly's public key needs to be known by the
> >framework. It would greatly simplify deployment where many
> >third-party components each have a different public key.
> >

You're going to have to modify the policy on each user's machine in order to trust this third party dll. You could do this through caspol:

caspol -ag 1. -strong 3rdparty.dll -noversion FullTrust

Or you can write a bit of bootstrap code at the beginning of your application that catches the security exception thrown by this third party dll and
modifies the security policy to allow trust to the dll. However, doing this will require that after the policy is changed, your application be restarted.
The class you're going to need to use in order to do this is System.Security.SecurityManager. You can use its PolicyHierarchy() method to get an
enumerator over the PolicyLevel's on the current machine. When you find the machine level (Where all the policy is currently stored), you can then
create a UnionCodeGroup object, using a StrongNameMembershipCondition object as its membership condition, and a PermissionSet
(PermissionState.Unrestricted) permission set as its permissions. After adding the code group, you could then call SecurityManager.Save() to
save the modified policy, and prompt your users to restart the application.

Another option would be to create the desired policy on your machine, and then using the .Net Framework Configuration Wizards, export the policy
to a .MSI file that all of your users could then install.

-Shawn
http://blogs.msdn.com/shawnfa

--

This posting is provided "AS IS" with no warranties, and confers no rights.
Note: For the benefit of the community-at-large, all responses to this message are best directed to the newsgroup/thread from which they
originated.
--------------------
>From: (E-Mail Removed) (Rodney)
>Newsgroups: microsoft.public.dotnet.framework
>Subject: Re: Avoiding adding another code group
>Date: 29 Jan 2004 15:11:16 -0800
>Organization: http://groups.google.com
>Lines: 45
>Message-ID: <(E-Mail Removed)>
>References: <(E-Mail Removed)> <(E-Mail Removed)>
>NNTP-Posting-Host: 218.101.103.107
>Content-Type: text/plain; charset=ISO-8859-1
>Content-Transfer-Encoding: 8bit
>X-Trace: posting.google.com 1075417876 9387 127.0.0.1 (29 Jan 2004 23:11:16 GMT)
>X-Complaints-To: groups-(E-Mail Removed)
>NNTP-Posting-Date: Thu, 29 Jan 2004 23:11:16 +0000 (UTC)
>Path: cpmsftngxa07.phx.gbl!cpmsftngxa10.phx.gbl!TK2MSFTNGXA05.phx.gbl!TK2MSFTNGP08.phx.gbl!newsfeed00.sul.t-online.de!t-online.de!
newsfeed.gamma.ru!Gamma.RU!news.maxwell.syr.edu!postnews1.google.com!not-for-mail
>Xref: cpmsftngxa07.phx.gbl microsoft.public.dotnet.framework:63991
>X-Tomcat-NG: microsoft.public.dotnet.framework
>
>Thanks Shawn - I am not familiar with either of these methods, could
>you please give more information.
>Many thanks,
>Rodney.
>
>
>(E-Mail Removed) ("Shawn Farkas") wrote in message news:<(E-Mail Removed)>...
>> Hi Rodney,
>>
>> There is no way to "pre-approve" a public key, however you could do one of two things. Since your app is already trusted, you could
>> programatically modify the security policy to include the third party's public key at startup. You could also Assert for the trust that the 3rd party
>> needs (with the standard disclamers about being very careful with asserts applying). Feel free to post back if you need details on either of
these
>> methods.
>>
>> -Shawn
>> http://blogs.msdn.com/shawnfa
>>
>> --
>>
>> This posting is provided "AS IS" with no warranties, and confers no rights.
>> Note: For the benefit of the community-at-large, all responses to this message are best directed to the newsgroup/thread from which they
>> originated.
>> --------------------
>> >From: (E-Mail Removed) (Rodney)
>> >Newsgroups: microsoft.public.dotnet.framework
>> >Subject: Avoiding adding another code group
>> >Date: 26 Jan 2004 13:59:02 -0800
>> >
>> >I have an application that has been deployed at a client site where it
>> >runs under a strong-named security context (it lives on the LAN ? is
>> >not installed on each machine, thus all assemblies must be signed and
>> >added to a code group on each client machine's runtime security
>> >policy).
>> >
>> >I now want to deploy an upgrade that uses a third-party component not
>> >used in the first deployment. I expect to have to add a new
>> >code-group to the runtime security policy on each client machine so
>> >the assembly can be called by my app.
>> >
>> >I was wondering if there was any way that the referenced assembly's
>> >public key is somehow pre-approved in the main assembly's manifest so
>> >only the main assembly's public key needs to be known by the
>> >framework. It would greatly simplify deployment where many
>> >third-party components each have a different public key.
>> >
>

""Shawn Farkas"" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> You're going to have to modify the policy on each user's machine in order
to trust this third party dll. You could do this through caspol:
>
> caspol -ag 1. -strong 3rdparty.dll -noversion FullTrust
>
> Or you can write a bit of bootstrap code at the beginning of your
application that catches the security exception thrown by this third party
dll and
> modifies the security policy to allow trust to the dll. However, doing
this will require that after the policy is changed, your application be
restarted.
> The class you're going to need to use in order to do this is
System.Security.SecurityManager. You can use its PolicyHierarchy() method
to get an
> enumerator over the PolicyLevel's on the current machine. When you find
the machine level (Where all the policy is currently stored), you can then
> create a UnionCodeGroup object, using a StrongNameMembershipCondition
object as its membership condition, and a PermissionSet
> (PermissionState.Unrestricted) permission set as its permissions. After
adding the code group, you could then call SecurityManager.Save() to
> save the modified policy, and prompt your users to restart the
application.
>
> Another option would be to create the desired policy on your machine, and
then using the .Net Framework Configuration Wizards, export the policy
> to a .MSI file that all of your users could then install.
>
> -Shawn
> http://blogs.msdn.com/shawnfa
>
> --
>
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> Note: For the benefit of the community-at-large, all responses to this
message are best directed to the newsgroup/thread from which they
> originated.
> --------------------

If the application lives on the LAN, I think a much easier way to deploy is
to assign trust not to the assemblies' key, but to the URL which they're run
from. We do no-touch deployment using many different third-party tools, and
as long as they don't require some sort of COM registration (no normal .NET
component will [Crystal reports is not a normal .NET component] ) nothing
needs to be done to the client in order to give trust to the new assemblies,
since they're located in the trusted location. This is somewhat less secure
than assigning trust to the strong key, but more than secure enough for our
software, which is a banking package that handles data processing, reports,
and document imaging. Really, I don't see any advantages to using the strong
key instead of the location, unless you're really paranoid about security,
but I could be missing something, so no offense.

Chris

""Shawn Farkas"" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> You're going to have to modify the policy on each user's machine in order
to trust this third party dll. You could do this through caspol:
>
> caspol -ag 1. -strong 3rdparty.dll -noversion FullTrust
>
> Or you can write a bit of bootstrap code at the beginning of your
application that catches the security exception thrown by this third party
dll and
> modifies the security policy to allow trust to the dll. However, doing
this will require that after the policy is changed, your application be
restarted.
> The class you're going to need to use in order to do this is
System.Security.SecurityManager. You can use its PolicyHierarchy() method
to get an
> enumerator over the PolicyLevel's on the current machine. When you find
the machine level (Where all the policy is currently stored), you can then
> create a UnionCodeGroup object, using a StrongNameMembershipCondition
object as its membership condition, and a PermissionSet
> (PermissionState.Unrestricted) permission set as its permissions. After
adding the code group, you could then call SecurityManager.Save() to
> save the modified policy, and prompt your users to restart the
application.
>
> Another option would be to create the desired policy on your machine, and
then using the .Net Framework Configuration Wizards, export the policy
> to a .MSI file that all of your users could then install.
>
> -Shawn
> http://blogs.msdn.com/shawnfa
>
> --
>
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> Note: For the benefit of the community-at-large, all responses to this
message are best directed to the newsgroup/thread from which they
> originated.