SitePoint Sponsor

User Tag List

Results 1 to 6 of 6
  1. #1
    SitePoint Guru Raskolnikov's Avatar
    Join Date
    Jul 2003
    Location
    USA
    Posts
    606
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    2.0 Membership and Roles

    I am slowly getting this figured out, but still need some info.

    Using 2.0's Membership and Roles access control, How do i set up access levels? Like Administrators can see this, Sub-Admins can see this, Regular Users see this? Is that what the Roles part is?

    On that note i am a bit confused with the roles. Just exactly what do they allow me to do?

    Ras

  2. #2
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,652
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Roles can let you do just about anything you want.

    I usually handle this in a couple ways. First, in the business libraries, I use PrincipalPermissionAttributes to block access to methods, properties and entire classes that really need special handling.

    Within the web application itself, you can block access to files and folders using the <authorization> section of the web.config. For sub-folders you can either put a web.config file in them or you can use the <location> element to keep everything in a centralized web.config.

    Finally, for some random purposes, I make use of the HttpContext.User.IsInRole() method liberally.

  3. #3
    SitePoint Guru Chroniclemaster1's Avatar
    Join Date
    Jun 2007
    Location
    San Diego, CA
    Posts
    784
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'll just tack a couple examples on to that.

    What you're describing is specifically what roles do for the loginview control. Users with different roles will see the webpage display differently depending on their role. It's fabulously wicked.

    You can also include role permissions in the sitemap so that different users can only navigate to certain sections of the website. Another probably more common way to handle this, is sticking whole website sections for each role in a folder and specifying who has access to the folder in its web.config just like Wyatt discusses.

    So let's say a "member" logs into a forum website and they have controls for creating posts on the forum. But using a loginview you can specify a modify and a delete control that are only available to someone who logs in with an "admin" role. Or...

    You can create a master index page for a corporate intranet. Using loginview you can specify a navbar that appears for any user that logs in from the "Accounting" department, and a different navbar for each "Sales", "HR", and "Operations". You simply create each department as a role. Then using web.config files you put all the accounting resources in one folder and lock it down so that only users with "accounting" or "admin" roles have access. Repeat the procedure for every department and your admin has control over everything, and each department can't mess up or even see the contents of the other departments resources. You typically leave company wide resources in the root which has permissions set to let any department have access.

    So roles let you do a lot for customizing webpages for specific blocks of users. Then you can take advantage of the Personalization provider for more specific user customization.
    Whatever you can do or dream you can, begin it.
    Boldness has genius, power and magic in it. Begin it now.

    Chroniclemaster1, Founder of Earth Chronicle
    A Growing History of our Planet, by our Planet, for our Planet.

  4. #4
    SitePoint Wizard
    Join Date
    Feb 2007
    Posts
    1,274
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Then I'll chime in as well. As wwb and chroniclemaster has explained, the access control system in ASP.NET is quite powerful.

    Some of the features (like declarative code access security) are quite advanced and is beyond what many websites need.

    To start out I'll recommend that you just use membership with the built-in rolw provider. If you place the restricted pages (e.g. site administration pages) into subdirectories of your site you can specify in a web.config in that directory that only specific roles (e.g. "Admin") have access to pages in that directory.

    Code:
    <?xml version="1.0"?>
    <configuration>
        <system.web>
          <authorization>
            <deny users="?"/>
            <allow roles="Admin"/>
            <deny users="*"/>
          </authorization>
        </system.web>
    </configuration>
    This is an example of such a file. It is probably a bit more explicit than need be, but when it comes to security I prefer a "better safe than sorry" approach. What it does is it rejects anonymous users (denoted by "?"), allows access for users who has the Admin role in their role list, and explicitly denies access for any other user.

    No code is needed for access control in the pages or webservices when they reside in this directory. It is specified declaratively in web.config.

    Now, if you are using the navigation features of ASP.NET, it will by default trim the sitemap for each individual user. It will actually look at the url, and if it refers to a page which is declaratively protected it will make sure the user has access. If not, the node will be taken out of the sitemap so that the user doesn't even see the node.

    This is by far the most common way to use roles and authorization is ASP.NET websites, and for simple sites the only one you'll need.

    Taking it from there you can use <location> elements for more fine-grained access control. You can also (as chroniclemaster laid out) start using page elements such as the LoginView which will display alternative content for different roles. You can start leveraging attributes to have security in-depth and finally you can resort to plain old programmatic checks.

    Just rest assured that the ASP.NET access control features can meet any requirement you may have. Even though the first steps may seem too simple, theres always a more advanced approach.

    My advice is to start using it gradually. Seperate the site into folders based on access required. This will often be sufficient, but if not you can take it from there.

  5. #5
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,652
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    No code is needed for access control in the pages or webservices when they reside in this directory. It is specified declaratively in web.config.
    This is why I use principal permissions to back things up. There is too much that can go wrong with declartive security for things that actually need to be locked down.

    On login views: I never have found them very useful, especially for interactive content. Main issue is one often needs to go use FindControl() to get at stuff in the login view. I find:
    Code:
    visible='<&#37;# User.IsInRole(RoleList.Whatever) %>'
    To be much more useful in many cases.

  6. #6
    SitePoint Guru Raskolnikov's Avatar
    Join Date
    Jul 2003
    Location
    USA
    Posts
    606
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    good to know fellas. thanks for the info. I will have to play around with this a bit.

    Thanks
    Ras


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •