Implementing Authentication and Authorization ASP.NET

The ASP.NET member ship provider and profile provider take care of the authentication and authorization for the application. In addition to this, an anonymous identification provider is used,which is not common among web applications because,unlike web portals,other web apps don’t require anonymous user creation on the first visit .The anonymous identification provider creates anonymous users whenever there is a cookieless visit , and takes care of creating entries in the aspnet_users table for the new anonymous user.

The web.config defines the providers in Example

Defining the providers with web.config

Defining the providers with web.config(continued)

However,there are several performance issues involved with anonymous identi fication providers, which are addressed later.

The anonymous identification provider is defined as:

An anonymous identification provider generates a cookie in the browser that identifies the anonymous user for 43,200 minutes(a little over 29 days) after the last hit.(The timeout is on a sliding scale, so each visit restarts the 29-day clock.) This means if a user closes the browser and comes back within a month, the user will be identified and will get the same page setup as it before. As a result, users can keep using the web portal without actually ever signing up.But if the browser cookie is cleared, the page setup will be lost forever.The only solution is to register using a login name and password ,so even if the cookie is lost, the user can log in to see his pages.

Web services, which let you modify data, are vulnerable to malicious attacks. For example, there is a web service method that moves a widget from one position to another .Imagine someone trying to call this web service with an arbitrary widget instance ID. The attacker will be able to mess up page setups by trying instance IDs from 1 to 1,000.To prevent such attempts, each web service operation needs to ensure operations are performed only on the objects that the caller owns .Remember from the previous example that you cannot the move position of a widget unless you are the owner .Such security checks are implemented in the business layer because if they were implemented in web layer ,the logic for checking owner ship ,which is a business rule, would get into the web layer .Some might argue that such checks can easily be put on the web layer to kick out malicious calls before they reach the business layer. But this pollutes the web layer with business rules. Besides maintaining such architectural purity, business layer methods are called from many sources, suchas a Windows service or a different web frontend . So,it becomes a maintenance issue to preserve conformance to such validations in all places. This topic is covered in more detail in Chapter.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

ASP.NET Topics