Adding Authentication and Authorization ASP.NET

Because it makes use of web services and asynchronous postbacks,a web portal is faced with four challenges:

• Authenticating the caller and ensuring the caller is a legitimate user on all asynchronous postback and web service calls.
• Authorizing calls to web services and asynchronous postbacks. Making sure the caller has the right to make that call.
• Preventing flooding.Making sure the caller cannot continuously call the service and flood the system.
• Preventing bots from hitting Default.aspx.

Web portals treat anonymous users the same way as a registered user.Although you might want to disable some features for anonymous users and make them available only to registered users, the main reason for registering is to save the pages permanently because anonymous cookies can get lost. Almost all web services can be called by any user except a user profile-related service, such as changing a user email address.

Although it sounds like security would be easier with web portal architectures, it is actually more complicated.For security purposes, you need to make sure each and every web service call is made on the caller’s pages or widgets.

For example, when deleting a widget from a page, you need to verify that the widget belongs to one of the user’s pages that just made the call.If it isn’t, then it’s definitely a hacking attempt. Similarly, when you remove a page, you need to make sure that it belongs to that user and not someone else. This is a big performance concern because such checks always require database calls.

If you had a registration-only site or an intranet- only site, you could skip these checks because you trust registered users more than anonymous users.But, since you have to support anonymous users, you cannot leave any web service method call unchecked.For example, when checking for a widget, you need to get the containing page of the widget and make sure it belongs to the user making the call.

Once you are satisfied that the call is legitimate, you canupdate the widget’s position. If you don’t do this, anyone can run a program and call the service by passing an arbitrary widget ID and change other users’ page setups.

Flood attempts are another problem. Anyone can continuously call “create a new widget” to the web service and flood the widget database with garbage widgets and thus make the database large and slow. So, you need to implement a quota on web service calls, e.g., a maximum of 100 calls per minute,100 widgets per page, or 10 registrations per IP per day, etc.

Adding Authentication and Authorization

The fourth problem is related to repeated page hits. Imagine hitting a web portal with cookies disabled. Every hit would be a first-time visit, which would force the web portal to generate a new user, create pages,and populate the page with widgets, which would create high database activity and enlarge database tables. So, you need to make sure no one is flooding your system by hitting the Default.aspx continuously. Also, you need to:

• Isolate bots and web crawlers
• Deliver different results from Default.aspx when a bot visits the site
• Prevent ASP.NET from creating a new anonymous user
• Create a maximum limit of cookieless hits to a page from the same IP

This last point is important, for example, an IP like can only hit Default. aspx 50 times an hour. But you can’t just set this to a very low value because several users using a proxy server will show the same IP.So,the challenge is to select a threshold value that does not bring down your server but also does not limit users using proxy servers. DoS attacks and prevention are covered in detail in the next section.

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

ASP.NET Topics