May include but is not limited to: application roles, schema ownership, execution context, Windows vs. SQL authentication, permissions and database roles
Let’s start with the boring definitions: authentication is the act of identifying yourself, while authorization is that one when you gain access to resources, based on your identity.
SQL Server allows two types of authentication methods: Windows authentication allows you to connect SQL Server with an existing Windows account , while SQL Server authentication allows connections from anywhere – as long as you set it up this way (which is a bad idea). You should use Windows Authentication, because this way you make your life easier (don’t have to store passwords in config files to connect), but if it isn’t possible, SQL Server authentication is the way to go.
Now how to build up your authentication model – there’s an easy way to go – connect with a fixed application credential. This way you can control what the app can do in the database server. However, sometimes you need more granularity – let’s say you are interested in who did what. If you connect with a single application credential, you’ll won’t get user-detailed information. Then you should use built-in user accounts.
In this post (which is the 100th one in the life of the blog), we’ll review three important security-related settings that you can define in your application’s web.config file, namely: authentication, authorization and impersonation. You’ll find a very thorough article about the topic here.
First a little terminology: authentication is the process of identifying, authorization is of checking rights. A common example: when you check-in to a plane, you show your ID, passport, etc. to identify yourself. Then you show your ticket for the given plane, to show that you are authorized to be there. It’s that simple. And impersonation is the process of taking someone else’s personality, which is a bad, bad thing. So long for terminology.
There are some a few authentication types in ASP.NET. Windows authentication uses the Kerberos protocol (or NTLM) to identify itself. Let’s consider it using with and without impersonation. You’d use Windows authentication with impersonation when:
I was evading the topic of security ever since I began posting my notes. It had a good reason: I’ve never worked with it. So I’d like to apologize here and now for the future mistakes in the following series of posts.
The first security-related objective we’ll revise is the accessing and modifying of the identity information. You can access the currently working user account (the entity under the current thread executes. There won’t be any calls to the stack to find an appropriate identity in it.). To achieve this, you’ll consider using two classes: the GenericIdentity and the GenericPrincipal classes. These classes have counterparts designed for using the Windows authentication services (like Active Directory). They are called WindowsIdentity and WindowsPrincipal respectively.
Of course, you can implement your custom Principal/Identity classes. In this case, your yet-to-come classes must implement IPrincipal or IIdentity. Let’s see a code sample on how to access the current user:
WindowsIdentity theIdentity = WindowsIdentity.GetCurrent();
Console.WriteLine(“Good news, you are authenticated!”);
GenericIdentity myCustomIdentity = new GenericIdentity(theIdentity.Name, theIdentity.AuthenticationType);
There are two main authorization types: File Authorization and URL Authorization. Let’s start with the latter:
Specified in web.config files, with a declarative syntax. URL Authorization only interested in the security status of the user, and the URL resource being requested, hence the name. If the page is forbidden for the requesting user, and forms authentication is used, then the user will be prompted to log in, thus redirected to the login page. If windows authentication is active, the user will receive a 401 – access denied page. It can be customized in web.config customErrors tag, if needed.