Authentication and Authorization

Authentication is the process of determining a user's identity. Often, authentication is described as forcing users to prove that they are who they claim to be. Authorization is the process of assigning permissions and restrictions to a given user after the user has been authenticated. If authentication fails, the user probably won't be able to use the application at all. If authorization fails, the requested action is aborted. In the Windows operating system, for example, users are authenticated at startup when they supply a username and password combination. Authorization is performed for operations such as deleting a file or attempting to launch Control Panel.

Authentication and authorization are what most programmers think of first when they tackle security. Using authentication and authorization, you can create an application that provides different features to different user classes. The distributed application programmer has two options when incorporating authentication into an application:

  • Use Windows authentication, which enables you to leverage existing account information and use the automatic directory-based security provided by IIS

  • Develop a custom authentication system, which will typically use a relational database (although other data stores are possible)

Windows authentication enables you to use built-in operating system services to manage and verify users. Some of the reasons you might use Windows authentication include the following:

  • To provide automatic authentication with IIS. This enables you to use challenge/response user verification, which is more secure than just sending username and password information over the Internet.

  • To use existing login accounts. If you're allowing remote access to an internal application, for example, users will already have an account on your domain server. No additional setup or configuration is required.

  • To use existing per-user permissions (such as access control lists). If you use Windows authentication with impersonation, the remote object executes under the identity of the client, ensuring that the client's permissions are evaluated for tasks such as reading a file.

A custom authentication system is generally the most flexible, scalable, and portable choice (meaning it can easily be migrated to a new system), but it also requires the most work. Custom authentication almost always works in tandem with a database. The reasons developers use custom authentication include the following:

  • To include additional user-specific information. This information can be added in a Users table or another linked table in a database. It can include everything from address or credit card information to application preferences.

  • To use a custom permissions system. You can associate users with groups that have application-specific permissions you define, without having to create numerous Windows groups.

  • To store user information independent of the Windows operating system, making it easier to move to another platform.

  • To give the application the complete capability to add, remove, or otherwise manipulate user records.

  • To optimize performance. Windows authentication can become a bottleneck. Database operations, on the other hand, can be optimized using connection pooling, query optimization, and caching.

  • To store other tables in a database that directly link to user records. Although you can simulate this with Windows authentication by using the user login name, it becomes more difficult to design queries for aggregate reports (such as a list of products ordered by a specific user).

In the enterprise world, Windows authentication is most often used when you're Web-enabling an internal application. In this situation, most users will already have login accounts. Custom authentication is the system of choice when your application is serving a third-party audience (such as eager e-shoppers) rather than a known audience of employees or associates.

That said, it is possible to use custom authentication with an internal audience. This approach (which you'll see again in the Chapter 18 case study) is particularly common when you need to store additional information about a user in a database or audit a user's actions. It's also possible, but impractical, to use Windows authentication with a large audience. One key stumbling block is that you have no easy way to provide self-registration (for example, a sign-up page on a Web site that enables customers to create their own accounts).



Microsoft. NET Distributed Applications(c) Integrating XML Web Services and. NET Remoting
MicrosoftВ® .NET Distributed Applications: Integrating XML Web Services and .NET Remoting (Pro-Developer)
ISBN: 0735619336
EAN: 2147483647
Year: 2005
Pages: 174

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net