The .NET Framework introduces a new layer of security, called Code Access Security. This layer lives on top of the OS security, and lets you control what a given assembly can and can’t do, just like the OS lets you define the rights of a user or group.
Before we dive into the details, there’s something (which may seem obvious at first, but is a particularly good thing to remember on the exam): whatever permissions you grant to a code, it will never have more rights than the user who runs it (just recall ASP.NET and IIS).
In the previous post, I wrote about permissions. The first important layer of CAS is the control of them. There are default permission sets, defining what an assembly can do. They are as follows:
|FullTrust||Exempts an assembly from CAS checks.|
|SkipVerification||Enables an assembly to bypass permission checks.|
|Execution||Enables an assembly to solely run.|
|Nothing||No permissions granted. Not even enough to run the given assembly.|
|LocalIntranet||The main restriction is that the assembly is not allowed to tamper with the file system, only through file dialogs.|
|Internet||A restrictive permission set, but safe.|
|Everything||Grants all permissions, but still checks the assembly.|
The classes related to controlling permissions and access for resources are live in the System.Security.Permissions namespace. There are a whole lot of permission classes for imperative security access settings, and each of them has its declarative attribute counterpart. There are three major categories of them:
- Code access permissions
- Identity permissions
- Role-based permissions
Code access permissions represents access to a given resource or the ability to perform a specific operation. For example, FileDialogPermission and RegistryPermission are classes which fall into the category of code access permission.
Now this one is short will be short and will have nothing to do with the title. I’ve found four enumerations in the System.Security.Authentication namespace. The most important of these is the SslProtocols enumeration. It has five possible values. You should know that the Ssl values (Ssl2 and Ssl3) are provided only for backward-compatibility and they are all superseded by the Tsl protocol. The fifth value is None, and it speaks for itself. Here’s a repeat for a better layout of this blog:
- SSlProtocols enumeration:
- Default (Ssl3 or Tsl will be used)
I forgot to mention that this enumeration controls which SSL protocol should be used for a given SslStream. Just in case if someone didn’t figure it out.
In this post we’ll examine the topics of compressing data, and the usage of the Isolated Storage feature of the .NET Framework. The namespaces are System.IO.Compression and System.IO.IsolatedStorage.
That’s an easy one, you’ll need to know two classes and an enumeration, namely: GZipStream, DeflateStream and CompressionMode. Even better GzipStream and DeflateStream can be used in the exact same way. The main difference, as you’d guess is the compression method. Both classes derives from Stream, so you can call the Read, Write and Seek methods. Both of them provides two constructors: the first one accepts a stream and a member of the CompressionMode enumeration. The second extends the first with a Boolean that indicates whether or not the stream should be kept open.
In this post, we’ll examine the built-in services in ASP.NET AJAX. You call these services in a same way as you’d call any custom web service from script, but there are some differences.
There are three built-in services in ASP.NET AJAX, namely:
- Authentication service
- Role service
- Profile service
To use these services, you must take two steps: first, configure that you’d like to call these services in your web.config file, then call the configured services from script in your pages. Both the configuration and the calling code is different for the three services, so lets get started with authentication.
HTML forms exist to collect data from the user. And this data, like every piece of user input, needs to be checked first for both security and logical reasons (what could we do with irrelevant data). There are two ways of checking the validity of user input: on the client side, and on the server side. Client side validation is swifter and more elegant, then posting back the data to the server, and the send back and error message. But we must implement both validation techniques, because a crafty attacker can bypass our client-validating methods, and send for example scripts or SQL commands back to our page to process them.