Authentication and Authorization | .NET Security and Cryptography

Before we can get anywhere in this chapter or the next , we must first come to grips with the questions of authentication and authorization . The central issue in both cases is that security must be able to ensure that only authenticated entities are permitted to carry out authorized actions. This issue therefore is resolved into two distinct questions:

Authentication : Who are you?
Authorization : Are you permitted?

Who are you? ^[3] can refer to either the identity of the user currently executing the code or the identity of the assemblies ^[4] that contain the code being executed. In fact, this distinction is the key difference between user-based security and CAS. In the case of user-based security, the question of authentication deals with the current user's identity, which is represented by the Principal and Identity classes. In the case of CAS, the question of authentication deals with the identity of the executing assemblies, which is represented by the Evidence class. This evidence can be used to discriminate on various aspects of the assembly, such as who digitally signed it and where it originated from. There may also be additional custom-assembly evidence that programmers may have defined.

^[3] This authentication question was made famous by Pete Townshend and Roger Daltrey in 1978.

^[4] The word assemblies is plural here because at any given moment, the currently executing method is actually performing work on behalf of all the method calls currently in the call stack. Since one method in one assembly may call another method in a different assembly, there are generally multiple assemblies that must be evaluated simultaneously according to the current security policy.

Are you permitted? addresses the issue of whether or not the current user or currently executing assemblies are authorized to do what it is being attempted. This question takes the answer to the first question (identity or evidence), and then makes a decision according to the currently established security policy. ^[5] As we shall see in more detail later, security policy is based on permissions that have been programmatically or administratively established.

^[5] Security policy is the configurable set of rules used by the CLR to make security decisions. Security policy is usually set by administrators. Security policy can be set at the enterprise, machine, user, or application domain levels.

There are several types of permissions, which are represented by the many classes that implement the IPermission interface. For user-based security, the PrincipalPermission class is used to check against the identity of the current user (i.e., the user attached to the calling thread). For CAS, the many CodeAccessPermission -derived classes are used to check against the individual permissions that have been granted or denied to all the callers of the currently executing method.