Gallery

.NET security

Posted on 26 Jul 2006 at 15:16

Thomas Lee looks at the security architecture of .net and delves into code access security

Security in both operating systems and applications has always been a major issue for OS and platform designers. In designing and implementing .NET, Microsoft took a number of steps to improve the security of applications developed using .NET, and to provide developers and IT pros with additional security features. These features go far beyond what's available under Win32, and they make it a lot easier for developers to produce secure code. This month, I'll be looking at the security architecture of .NET and how it works. Key security features within the .NET Framework include:

• User authentication: .NET allows you to exploit Windows user authentication for console, GUI and intranet apps, and when using ASP.NET your applications can also provide Forms Authentication and integrate with Microsoft Passport.

• Role-based security: this makes use of Windows security groups and provides a means to develop custom roles to satisfy intranet and internet needs.

• Cryptography: .NET provides many features for encrypting and decrypting your data, including symmetric and asymmetric encryption, secure hash functions and digital signatures.

• Code Access Security: this is an additional feature of .NET that enables you to manage what an application is allowed to do, irrespective of who's running it.

Security in .NET is a huge subject, and large books have been written on the topic. Since I can only scratch the surface in this column, I'll be concentrating on the last of these security features, Code Access Security.

Both MS-DOS and the earlier versions of Windows were designed without much regard for security. PCs in those days were truly personal computers, used by only one person, and so security was far less important than functionality. Once PCs began to be networked, more security was required, but it was implemented by functions that were for the most part bolted on as a bit of an afterthought. That all changed with Windows NT, when Microsoft announced that Windows had become a multi-user OS and tackled security where it was needed at OS level. Starting with NT 3.5 and continuing with Windows XP, Windows Server 2003 and the forthcoming Vista and Longhorn Server releases, Microsoft introduced a number of security features into the very heart of the OS.

Under recent versions of Windows, the user is a security principal: that is, the user is the first entity to be authenticated by Windows. Once authenticated, a user is able to do a variety of things - or else is prohibited from doing them - based on a number of access controls. With this kind of security scheme, it's the user who gets authenticated and is then authorised to perform operations based on the identity that's established.

Windows implements this scheme via a complex process that involves mandatory logons, security tokens and access control lists. The token is created at logon time and contains Security Identifiers (SIDs), which are used to uniquely identify the user to each of the security groups the user belongs to. In addition, each resource (file, share, folder or whatever) has an access control list that identifies those users/groups who are allowed to access that resource, and the limits of their access. For example, a particular file could be granted read-only access for all users, but read/write access to system administrators only. Each time a user attempts to access a resource, for example to open a file, the user's token is checked against the resource's access control list in order to enforce the authorisation.