tags:

views:

110

answers:

3

We have a server application that we want to restrict non-users from triggerring it off from other machines or even by double-clicking from any share.

However, it should be easy for dev's to run it on their boxes.

What are the various ways to enforce this policy?

+2  A: 

There are a few ways to control access of assemblies.

We protect our assemblies on a license basis, so only workstations with the license are able to run the assembly.

We allow Developers to run the debug build unchecked. We of course keep a tight control on the debug builds. you could put additional checks in the debug builds for more security if necessary. Or issue licenses to the developers.

For our debug builds, we add a license in the debug code wrapped in "#IF DEBUG" to make sure it is not compiled into the release build.

I am not saying this is the best way, but this is the method we use.

John Christman
I like the #IF DEBUG route, that's what I've done. Also, if the OP doesn't already have a formal build process this might be the right motivation for them to implement one.
overslacked
+2  A: 

I suppose that you are looking for a simple failsafe, and not an air tight access control...

Put the machine name in the config file, and compare that against the machine name when the application starts. That way you can't run it anywhere else by mistake, and it's easy enough to change when developing, or if the application is moved.

Guffa
+2  A: 

One idea: One could use a registry key that needs to be present in order to run.

Another: One could require an X509 certificate be installed in the keystore to run

Another: Use System.Security.Permissions and restrict operation to a set of users or a group.

etc.

Demi