Defining Effective Imperative Security

Imperative security appears as statements within the application code. You define a security object, and then use methods provided by that object to grant or deny access to various resources. CLR processes these statements at runtime. Consequently, imperative security doesn’t appear as part of the application manifest. The example in the “Executing Code in the Managed Environment” section of Chapter 1 shows just one way to use imperative security in an application.

Declarative security is important because it provides so many good features, such as instant documentation and good metadata access. In fact, declarative security may provide so many good features that you might be tempted to use it exclusively. However, you do need to use imperative security in some situations.

Whenever a security need requires a dynamic data path or other resource information, you must use imperative security. Because the compiler processes declarative security attributes during the compilation stage, you can’t change it at runtime. Using imperative security is the only way around this problem.

Many developers also find that imperative security is inherently easier to use because it appears as statements. Using declarative security means placing all security requirements at the very beginning of a module, which breaks up the code flow and means moving back and forth to really understand what the code means. In addition, attribute coding is relatively new. Most developers who learned to code before .NET arrived on the scene will find using statements more intuitive because they’ve always used statements in the past.