How CAS Is Used

CAS provides a very useful security model, which is quite distinct from, but complementary to, user -based security. ^[14] Let's look at some of the ways that CAS can be used to solve security problems that are not effectively handled with user-based security techniques alone.

^[14] Unlike CAS, user-based security does not seem to be referred to in the literature by an acronym.

Flexible Security

CAS provides a flexible security layer over user-based security that allows for varying degrees of trust. This is somewhat similar to the Internet Explorer concept of security zones but is much more configurable and extensible. CAS minimizes the amount of code that must be fully trusted, and it takes into account the fact that trust is not always an all-or-nothing proposition.

As described in the previous chapter, user-based security is great for situations where you have a manageable number of users and groups that you can effectively evaluate in terms of trustworthiness . But what if there is no limit to the number of users? For example, what about implementing a secure public Web service? What about developing a reusable library that might be called upon by hundreds of programs written by unknown programmers that could then be executed by virtually anyone anywhere ? It would not be practical to create a user account or role and assign individual privileges for an arbitrarily large number of users. The traditional solution was to use a special anonymous account to represent unknown users, allowing you to broadly define anonymous user privileges. The Web server then temporarily impersonates the anonymous user to service the request. This is fine in many cases, but sometimes you may need finer control over the privileges granted to anonymous users, in a way that might vary, depending on the nature of the code that is being executed. This is another situation where CAS can provide greater flexibility.

The Luring Attack and Walking the Stack

User-based security by itself is also problematic in situations where an evildoer lures innocent users running trusted programs into unintentionally doing nasty things. If you are the parent of a teenager, you are perhaps familiar with the need for limiting certain permissions that are not motivated by a lack of trust in your child but rather by your mistrust of your child's peers. In the same way, whenever you are executing trusted code that interacts with code that originates from unknown sources, you may need to manage the risk by controlling the privileges of the trusted code as well. You should always try to limit what can be done to the smallest set of actions that you expect may be legitimately required. This works well for code security, but of course for teenager security, your mileage may vary!

Since a less trusted assembly has reduced permissions granted to it, it probably cannot do much damage on its own. More trusted code is typically granted greater permissions, so it should somehow check on its callers before doing anything that could be potentially dangerous. The CLR provides a nifty, built-in feature called stack walking that makes this security check on the caller possible. Whenever you call a method that demands a request for a particular permission, the CLR performs a stack walk, first checking the immediate caller and then continuing up the call stack until it is satisfied that all callers have been granted the specified permission. If security policy does not permit the action, or if any callers have denied the permission, then a security exception is thrown, and the action is prevented.