Chapter 13 : Securing .NET Applications with Access Databases

Writing secure applications is always an important topic, but its urgency heightens whenever databases are part of a solution. As a Microsoft Access database developer, you can take comfort in knowing that the .NET Framework offers new security features while preserving one of the best ways to lock down applications so that only legitimate users have permissions to access the databases that comprise your solutions. In addition, some of the new .NET security features are particularly easy to implement.

This chapter equips you to start securing your Access database applications in three ways. First, it systematically reviews the core features of the new security offered by the .NET Framework. This review introduces and highlights distinguishing features of .NET security elements, such as code access security, role-based security, and cryptography. Second, the chapter demonstrates how to apply traditional user -level security to a .NET Windows application for an Access database. This section includes a quick review of user-level security as an introduction to tightly securing a sample Access database. Then, the section presents code showing how to use ADO.NET in concert with user-level security to manage secure data access and data manipulation. The chapter s closing section presents forms authentication for .NET Web applications. This easy-to- implement technology can lock down the Web forms at a Web site until users authenticate themselves . Forms authentication offers several strategies for authenticating users, but this presentation illustrates how to use a table in an Access database to validate the credentials of entrants to a Web site.

Overview of .NET Security

.NET Framework security focuses heavily on built-in policies for administering the security of applications. In addition, the .NET Framework offers tools and policies for customizing built-in security policies. Many .NET Framework security features cater to the skills of system and machine administrators. Database developers need to gain a familiarity of .NET Framework security policies so that they can work with administrators to ensure database applications have a proper set of policies that enable those applications to run without interference from security settings. Database developers also must learn that using inappropriate security settings could jeopardize the integrity of the systems on which their applications run.

Database developers need to understand that .NET security techniques do not replace database security practices. Instead, .NET security complements database security. It is critical that database developers master techniques for securely administering their databases. By having a thorough understanding of database security techniques, a developer can understand how to mix and match database security practices with .NET Framework system security policies.

Code Access Security

Code access security policies determine what resources a .NET Framework assembly can reference. The assembly is the basic security unit in the .NET Framework security model. In the examples presented throughout this book, an assembly maps to a project folder. In order to take advantage of code access security, your assemblies must be type safe. This requirement restricts the data types that the methods in an assembly can accept as well as the memory locations that an assembly can reference. Type-safe code helps prevent buffer overruns, which is one common way errant code can break through traditional security safeguards or inappropriately take over resources such as Microsoft SQL Server. The Microsoft Visual Basic .NET compiler returns type-safe code, but not all compilers for .NET languages necessarily do this.

Note  

The .NET Framework enforces rules that control how code operates through code grants . The grants for an assembly specify the permissions available to the code in the assembly. For example, code that is not type safe cannot run on another computer unless an administrator explicitly permits code to bypass verification for type safety.

From the conceptual level at which this presentation addresses code access security, you need a grasp of evidence, permissions, and security policies. These concepts interact with one another to determine how code operates. For example, the common language runtime (CLR) examines the evidence for an assembly relative to default or customized security policy settings for a computer. Evidence can include where an assembly came from or who its author is. For example, code from the Internet will typically not enjoy the same permissions as code from a local computer. However, code published by a trusted author such as a contractor doing custom work for your organization might override restrictions that normally apply to code derived from the Internet.

Code access permissions are gateways to the resources and functions on a computer. Selected classes that provide code access permissions have names that reflect their uses, such as the following:

• OleDbPermission for OLE DB .NET Data Provider permissions

• SqlClientPermission for SQL Server .NET Data Provider permissions

• FileIOPermission for permissions to read, write, or append files

• WebPermission for permissions to connect to Web addresses

• SecurityPermission for permissions to manage .NET Framework security

See the Code Access Permissions topic in the Microsoft Visual Studio .NET documentation for additional permission class names. Permissions are two-sided tools. On one side, an assembly can present, or demand, the permissions that it needs to run successfully. On the other side, a machine can assign a set of permissions to an assembly based on the evidence for an assembly. If the permission that an assembly needs to run is not available from a machine, the code in the assembly throws an Exception object. Assemblies can optionally contain code to gracefully handle exceptions. For example, if an assembly requires the Microsoft.Jet.OLEDB.4.0 provider but the machine restricts access to this provider, the assembly will fail to load successfully.

Security policy is the set of permissions that apply to the operation of code on a machine. Machine and enterprise administrators can configure security policy permissions for specific requirements. An enterprise administrator can restrict access from individual software publishers (based on their strong name or cryptographic signature) as well as block the downloading of applications from specific Web sites. The .NET Framework simplifies the administration of permissions by assigning assemblies to code groups based on evidence about an assembly. Administrators assign permissions to code groups and inherit permissions based on their membership in a code group . Two tools are available for helping administrators to administer security policy: the .NET Framework Configuration tool (Mscorcfg.msc) and the Code Access Security Policy tool (Caspol.exe).

The .NET Framework permits the administration of security policy at any of four levels, including an enterprise, a machine, an individual user, and an application domain. Application domains define secure, isolated boundaries between two or more processes that can run concurrently on the same computer. The security policy levels appear in hierarchical order with the enterprise level being the highest and the application domain level being the lowest . Typically, different individuals will administer security policy at different levels. A lower level cannot repeal a restriction set at a higher level, but an administrator of a lower level can tighten a restriction so that code meant to run at a higher level throws an Exception object instead of successfully operating. For this reason, a higher level can specify that lower levels cannot alter a security policy setting.

The elaborate .NET Framework security architecture enables administrators and developers to work together to protect organizations against typical kinds of security problems. For example, this section described earlier how type-safe code guards against buffer overruns. The call stack is another construct that works in combination with assembly permissions. The call stack can guard against lurking attacks ”for example, one in which code without permission to perform a task invokes trusted code to perform that task. The CLR examines the hierarchy of assembly calls in the call stack before enabling a method. Therefore, an Internet application cannot invoke another application to read or write to a machine s hard drive by invoking another trusted assembly to perform the task for the Internet application.

Role-Based Security

Code access security is about managing permissions for code ”namely, assemblies ”to access resources or perform actions. Role-based security applies the same notions to users and groups of users. As an Access developer, you have experience with role-based security for user-level security with Access database files. We will examine Access user-level security more closely in the next section when demonstrating how to use it with ADO.NET objects. For now, focus on the fact that user-level security makes use of users and groups to control the kind of permissions that users have to the objects in an Access database file. With role-based security, you can define similar kinds of identities as users and groups. Then you can specify permissions for these identities, or you can enable functionality in your application based on individual identities or group memberships.

Access user-level security is an example of a security model for a database. Role-based security in the .NET Framework is for your custom applications. The Access user-level security model applies exclusively to the Access database files. The role-based security model in the .NET Framework is flexible because it allows you to apply a single model to multiple databases. For example, although the details of the Access and SQL Server security models differ , you can expose the same kind of security for both Access and SQL Server databases with the .NET Framework s role-based security. When you need a common application security model for multiple types of databases, the .NET Framework s role-based security model offers an interesting option. If you know that your application will always work exclusively with one type of database (which might be true for some Access developers), using the native security model for a database can simplify your development. This is especially true if you are already familiar with a security model for the type of database that your application references.

Implementing role-based security in the .NET Framework requires up to three steps. First, you define the Principal and Identity objects. The Principal object contains an Identity object. The Identity object holds information identifying a user, and the Principal object specifies roles to which its Identity object can belong. You can use the Principal object and its associated Identity object to authenticate and authorize a user. Authentication is the process for verifying that a user is who she says she is. Authorization is the process of assigning rights to a Principal object so that it can perform actions. The .NET Framework provides two types of Principal objects. The WindowsPrincipal object enables your application to check the Windows group membership of a Windows user. This relieves your application from managing the authentication process because Windows does this when a user logs on to a Windows server. The GenericPrincipal object is a generic principal for which you programmatically manage authentication as part of your application.

Note  

Principal objects are associated with threads within a process. Any one process controlled by a procedure can have multiple threads. For example, you can associate a separate thread with each instance of a class in an application.

The second and third steps for implementing role-based security can work together to enable permissions for Principal objects. The second step creates a PrincipalPermission object. This object designates an Identity object and a role. The third step can demand the PrincipalPermission object. If the Principal object for the current thread does not match the Identity and role demanded via the PrincipalPermission object, the .NET Framework throws an Exception object. Otherwise, the code in the third step operates normally. Instantiating and demanding a PrincipalPermission object is optional because you can directly check the Identity and/or role of the Principal for the current thread.

Cryptographic Services

Cryptographic services represent another major security element within the .NET Framework. You can achieve three primary security objectives with cryptography in the .NET Framework. First, you can protect your data or your identity. For example, you can encrypt/decrypt user logon credentials as part of a custom logon application. Second, you can verify that data was not altered during transmission. Third, you can learn the publisher of an encrypted document. The Cryptographic Services topic in the Visual Studio .NET documentation provides links for drilling down further into .NET Framework implementations of cryptography.

Note  

If you re running Microsoft Windows 2000 or Microsoft Internet Explorer version 5.01 or earlier, you need to download and install the High Encryption Pack to ensure the highest level of encryption (128 bits). This is available via Microsoft s Web site at http://www.microsoft.com/windows/ie/downloads/recommended/128bit/ .

For encrypting and decrypting documents, including datasets as XmlDataDocument objects, you can use private key encryption. This style of encryption is commonly referred to as symmetric encryption because the same key encrypts as well as decrypts documents. The .NET Framework offers several styles of symmetric encryption as separate classes. All symmetric encryption styles can process documents as a series of blocks, such as a series of bytes. To disguise the encryption process, the encrypted value for each block uses some information from the prior block to designate the encrypted value for the current block. An initialization vector plays this role for a document s first block. With symmetric encryption schemes, you can specify the encryption style with three elements: the name for the encryption class, the encryption key, and the initialization vector.

Public key encryption is suitable for encrypting small amounts of data. This style of encryption is referred to as asymmetric encryption because it relies on two different yet linked keys. Data encrypted by one key can be decrypted by the other key. The two keys for this style of encryption are known as the public key and the private key . You can distribute the public key widely without security. A recipient can use the public key to decrypt a document encrypted by the private key. Another use for public key encryption is the transfer of the encryption key for a symmetric encryption style. By using public key encryption to pass the symmetric encryption key, you can securely share a symmetric encryption key between two users. This technique allows public key encryption to support the application of private key encryption. In addition to encrypting documents, public key encryption is useful for making digital signatures to identify a publisher. Therefore, releasing a private key will allow others to impersonate a publisher.

The .NET Framework implements both private key encryption and public key encryption. Creating a cryptographic scheme and even implementing its code is an advanced topic. See the .NET Framework Cryptography Model and Creating a Cryptographic Scheme topics in the Visual Studio .NET documentation for more details. You can find some illustrative sample code in the selection of topics within the Cryptographic Tasks topic in the Visual Studio .NET documentation. Furthermore, Richard Mansfield s DevX Web site article about Visual Basic .NET cryptography, Keeping Secrets: A Guide to VB .NET Cryptography, contains some instructive sample code: http://www.devx.com/security/articles/rm0802/rm0802.asp .