Examining ASP.NET 2.0's Membership, Roles, and Profile - Part 12

Posted by: 4GuysFromRolla.com Headlines, on 23 Jul 2008 | View original | Bookmarked: 0 time(s)

Several of the earlier installments in this article series examined how to apply authorization rules in order to prohibit particular users, roles, or classes of users from accessing particular resources. For instance, Part 2 showed how to define URL-based authorization rules in web.config for roles. With just a bit of XML markup, it is possible to block particular users or roles from visiting certain web pages. Just installments also looked at using the LoginView control, which displays different markup based on whether the user is authenticated or not (and can also be used to display different markup based on the currently logged in user's role). There are also programmatic techniques you can use to determine the identity of the currently logged on user and what roles she belongs to.

The URL-based authorization, LoginView control, and programmatic techniques can be used in tandem to ensure that a user does not visit a page or perform some operation if she is not authorized. But what if you forget to implement one of these safeguards? For example, imagine that you have a web page that includes a button that, when clicked, perform some task that is only intended for administrators. You could put this button in a LoginView control or you could use programmatic techniques to ensure that only users in the appropriate role (say, Admin) saw the button. But what if sometime later you, or another developer, removed this check by accident? The net result would be that any user visiting the page could perform the administrator-only operation! Whoops!

To reduce the likelihood of such security mishaps, the .NET Framework includes capabilities for declaratively asserting permissions (via attributes) on methods and classes. In a nutshell, you can add such attributes to ASP.NET pages, their code-behind classes, and your business logic and data access layers. With these attributes in place, your visitors will be barred from performing unauthorized actions, regardless of whether there are any security holes in the user interface. Read on to learn more!
Read More >

Category: ASP.NET | Other Posts: View all posts by this blogger | Report as irrelevant | View bloggers stats | Views: 1316 | Hits: 32

Similar Posts

  • Examining ASP.NET 2.0's Membership, Roles, and Profile - Part 18 more
  • Scenarios for WS-Passive and OpenID more
  • ASP.NET Membership Tip: Requiring New Users To Change Their Password When Logging On For The First Time more
  • Why Embedded Silverlight Makes Sense more
  • Lets build an Application Together. more
  • May 30th Links: ASP.NET, AJAX, ASP.NET MVC, Visual Studio more
  • Next Four Hosting Tutorials Now Online more
  • Nov 6th Links: ASP.NET, ASP.NET AJAX, jQuery, ASP.NET MVC, Silverlight and WPF more
  • Email Verification for New Accounts via ASP.NET's Membership Framework more
  • .NET Framework Client Profile more

News Categories

.NET | Agile | Ajax | Architecture | ASP.NET | BizTalk | C# | Certification | Data | DataGrid | DataSet | Debugger | DotNetNuke | Events | GridView | IIS | Indigo | JavaScript | Mobile | Mono | Patterns and Practices | Performance | Podcast | Refactor | Regex | Security | Sharepoint | Silverlight | Smart Client Applications | Software | SQL | VB.NET | Visual Studio | W3 | WCF | WinFx | WPF | WSE | XAML | XLinq | XML | XSD