Can you verify AppDomain when assemly loads?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I was wondering if there any security mechanisms in the framework which
enables me to identify the appdomain which my dll is being loaded into? For
ex. if I want to make sure that the appdomain was created by a program from
our company.

One approach is probably to use AOP and intersept all message calls,
checking some pre condition, but this sounds like a lot of overhead. Are
there any ways enable/disable AOP at runtime. For example veryfing the user
at the first method call and then removing all method interceptions?
 
Not really. Even if you could find a way to intercept all messages, there
would be no way to tell whether the evidence the app domain presents about
itself is accurate or spoofed. Why are you concerned about the identity of
the invoking code--licensing or trust issues?
 
I would be interested to hear why you want to do this. If you just
need to make sure that your callers are from a list of predefined
assemblies you could use the
System.Runtime.CompilerServices.InternalsVisibleTo attribute to list
any assemblies able to call your library and have any class that you
want protected be marked as internal.

This wouldn't give you the ability to just run whenever a new AppDomain
from your company called your code but a more granular level of control
might be what you want.
 
I want to do this to avoid third party vendors from putting a using statement
refering to our biz logic dll. You solutions seems to be what i'm looking
for, than you.
 
I want to do this to avoid third party vendors from putting a using statement
refering to our biz logic dll.
 
But why? Because you want to prevent folks from using your API without
paying a licensing fee or because you want your dll to be able to trust its
calling code to have reliably performed some operation (e.g.: data
validation or user authentication/authorization)?
 
If this is basically an intellectual property issue, why not use a licensing
approach? If that seems like too much work, then the friend assemblies
approach mentioned by dorminey might be suitable if you're using fx 2.0. If
you're still using fx 1.1, it might seem tempting to use link demands for an
identity permission (e.g.: StrongNameIdentityPermission), but be aware that
these are quite easy for highly privileged code to bypasse, and they are
automatically passed by fully trusted code under fx 2.0.
 
I'm using the 2.0 framework. I'm very interested in learning more about
licensing, ff you have some good links/resources regarding licensing, I would
very much like to have them.
 
For a quick intro, see
http://msdn2.microsoft.com/en-us/library/fe8b1eh9.aspx. For something a
little more complete, you might want to take a look at
http://www.developer.com/net/net/article.php/3074001, which does delve into
more complex licensing scenarios after covering the basics of control
licensing.

If you only want to prevent others from using your code, simply writing your
own LicenseProvider and generating licenses manually would probably be quite
sufficient. However, if you're thinking of actually selling licenses to use
your API, you might want to consider using a somewhat more complete
licensing solution. There are a few listed at
http://sharptoolbox.com/categories/licensing.
 
Back
Top