Hi Dave,

I think how to config the security setting should be depend on your
scenario.
The CAS worked based on Evidence(e.g. Strongname, url....), and it is used
to control Restrict which code can call your code, what your code can do.
You should make sure what your assembly A will do and what not do. Then the
other assembly B call the A, it will have evidence so that CLR will get it
permission dependent on your setting. But no matter what permission the B
have, it can not call the A's method(or via delegate, as long as the DLL
code is on the call stack), if we have set the A have no the permisson.

Also if certain Assembly C have another evidence want to call A, but C have
no the permisson that A have, then the C call A's method will still fail.

So I strongly recommended your look through all the links below and consult
the .NET Security Book.

Avoid Using APTCA
If you use APTCA, your code is immediately more vulnerable to attack and,
as a result, it is particularly important to review your code for security
vulnerabilities. Use APTCA only where it is strictly necessary.

In the context of server-side Web applications, use APTCA whenever your
assembly needs to support partial trust callers. This situation can occur
in the following circumstances:

Your assembly is to be called by a partial trust Web application. These are
applications for which the <trust> level is set to something other than
Full. For more information about partial trust Web applications and using
APTCA in this situation, see Chapter 9, "Using Code Access Security with
ASP.NET."
Your assembly is to be called by another assembly that has been granted
limited permissions by the code access security administrator.
Your assembly is to be called by another assembly that refuses specific
permissions by using SecurityAction.RequestRefuse or
SecurityAction.RequestOptional. These make the calling assembly a partial
trust assembly.
Your assembly is to be called by another assembly that uses a stack walk
modifier (such as Deny or PermitOnly) to constrain downstream code.

RequestOptional
If you use SecurityAction.RequestOptional method, no other permissions
except those specified with SecurityAction.RequestMinimum and
SecurityAction.RequestOptional will be granted to your assembly, even if
your assembly would otherwise have been granted additional permissions by
code access security policy.

Authorizing Code
Code access security allows you to authorize the code that calls your
assembly. This reduces the risk of malicious code successfully calling your
code. For example, you can use identity permissions to restrict calling
code based on identity evidence, such as the public key component of its
strong name. You can also use explicit code access permission demands to
ensure that the code that calls your assembly has the necessary permissions
to access the resource or perform the privileged operation that your
assembly exposes.

Usually, you do not explicitly demand code access permissions. The .NET
Framework classes do this for you, and a duplicate demand is unnecessary.
However, there are occasions when you need to issue explicit demands, for
example, if your code exposes a custom resource by using unmanaged code or
if your code accesses cached data. You can authorize code in the following
ways:

Restrict which code can call your code.
Restrict inheritance.
Consider protecting cached data.
Protect custom resources with custom permissions.

Code Access Security in Practice
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secmod/html
/secmod81.asp

Providing information for Security Policy administrators has side effects
RequestMinimum and RequestOptional were discussed in my previous article.
RequestMinimum doesn't cause any change to Security Policy. In minimum.cs
the UIPermisssion's AllWindows permission was requested:

[assembly:UIPermission(SecurityAction.RequestMinimum,
           Window = UIPermissionWindow.AllWindows)]

If you change the UIPermission in SamplePS Permission Set to "No Windows",
the code fails to run. However, the name Request is potentially misleading.
If you don't have the permission, your program will fail with a
PolicyException before your code ever runs. RequestMinimum tells the system
that you absolutely must have these permissions to run. If that's not the
case, you're better off not using a RequestMinimum. Check what permissions
you have with a Demand, and take the appropriate recovery path in your code
if you don't have the permissions.

RequestOptional is even trickier. The file optional.cs in the
RequestOptional sample has two RequestOptional actions commented out:

//[assembly:UIPermission(SecurityAction.Request
Optional, Window = UIPermissionWindow.AllWindows)]
//[assembly:FileIOPermission(SecurityAction.Request
Optional, All = @"c:\")]

If you run the program, it works. Uncomment one of the actions, and run the
program. You can't execute the action the other request refers to!
Uncomment both. The program runs! Change one of the actions to a
RequestMinimum¡ªthe program still runs. RequestOptional implicitly refuses
all permissions that weren't in a RequestMinimum or a RequestOptional. It's
as if a RequestRefuse were entered for every other permission covered by
your system's Security Policy. No mere request, this Security Action,
either. Note that the failure resulting from a RequestOptional, however,
causes a SecurityException to be thrown when the action with the
unavailable permission is requested. RequestOptional never implicitly
refuses the Execution permission.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnhcvs03/ht
ml/vs03b1.asp

Programming .NET Code Access Security
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnhcvs03/ht
ml/hcvs03a11.asp

Understanding .NET Security Actions
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnhcvs03/ht
ml/vs03b1.asp

Requesting Optional Permissions
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpconrequestingoptionalpermissions.asp

Best regards,

Peter Huang
Microsoft Online Partner Support