A common security requirement for Web sites is to allow only some members or other authenticated users to see certain pages. ASP.NET role management provides a way to restrict access to Web files based on security roles. Site-map security trimming provides a way to hide navigational links in a site map, also based on security roles. For information about role-base security, see Understanding Role Management [ http://msdn.microsoft.com/en-us/library/5k850zwb.aspx ] .
Consider the following navigational structure, which is displayed in an ASP.NET page.
Home |
Clients who are not members of a role called Customers are restricted from viewing the Support Web page by an ASP.NET access rule that is configured for the Support.aspx page.
To hide the Support link in the navigational display, configure the site-map provider in the Web.config file to enable security trimming. No additional changes are needed because the application will use ASP.NET URL authorization and file authorization to hide the link to the Support page. The XmlSiteMapProvider [ http://msdn.microsoft.com/en-us/library/system.web.xmlsitemapprovider.aspx ] control that is included with ASP.NET version 2.0 automatically performs authorization checks against each site-map node by using the URL- and file-authorization features.
If you want show the Support link to clients who are not in the Customers role, you can use the roles attribute in the site-map node for the Support.aspx file. The roles attribute expands access to a site-map node beyond the level of access that URL authorization and file authorization grant.
The following code example sets the roles attribute for the Support page to Customers. After enabling security trimming, this setting allows users in the Customers role to view the navigation link to the Support page, even if they are not permitted to view the actual file by URL authorization or file authorization.
<?xml version="1.0" encoding="utf-8" ?> |
Users who are not members of the Customers role would see the following navigational structure if they are restricted from viewing the Support page because of URL- or file-authorization rules.
Home |
Security trimming works in conjunction with ASP.NET roles. Therefore, pages must be restricted by using access rules (allow and deny elements) for security trimming to work. For more information about access rules, see Managing Authorization Using Roles [ http://msdn.microsoft.com/en-us/library/9ab2fxh0.aspx ] .
Security trimming is not enabled by default, and it cannot be enabled programmatically; it can only be set in the Web.config file. This is also true for any custom class that inherits from the SiteMapProvider [ http://msdn.microsoft.com/en-us/library/system.web.sitemapprovider.aspx ] class.
To enable security trimming, you need to configure a siteMap Element (ASP.NET Settings Schema) [ http://msdn.microsoft.com/en-us/library/1e333zt4.aspx ] element in your Web.config file. If your site map uses the default ASP.NET site-map provider, then the Web.config file might not contain a siteMap Element (ASP.NET Settings Schema) [ http://msdn.microsoft.com/en-us/library/1e333zt4.aspx ] element, in which case you will need to add one. The following code example adds the default site-map provider and enables security trimming.
<system.web> |
The security-trimming feature uses URL authorization on each request to determine whether a user has access to a URL that is associated with a siteMapNode element. This extra work reduces performance depending on the number of nodes that are being authorized. When security trimming is enabled, you can use the following methods to improve performance:
Limit the number of nodes in the site-map file Site-map files with more than 150 nodes can take substantially longer to perform security-trimming operations.
Set the roles attribute explicitly on siteMapNode elements Note that setting the roles attribute to a wildcard character, or asterisk (*), should be used only for nodes that can safely be displayed to any client. The presence of a roles attribute allows ASP.NET to bypass URL authorization for the URL that is associated with the siteMapNode when a user belongs to one of the roles that is listed in the attribute.
To prevent the unintended trimming of child site-map nodes, configure authorization rules and roles attributes carefully. Consider the following navigational structure, which is displayed in an ASP.NET page.
Home |
The URL- or file-authorization rules set on the Products.aspx file should not be more restrictive than the authorization rules that are set on the Hardware.aspx file. Otherwise, the Hardware link will be hidden from users who should be able to view it because the parent link to Products will be hidden. To expose the hidden links, add to both site-map nodes a roles attribute that lists the neglected ASP.NET roles.
It is recommended that the root node in a site map allow everyone access. To do this, set the roles attribute to an asterisk (*), or wildcard character, as shown in the following code example.
<?xml version="1.0" encoding="utf-8" ?> |
In a site map, you can reference URLs that are outside of your Web application. Access to a URL outside of the application cannot be tested by ASP.NET. Therefore, if you enable security trimming, the site-map node will not be visible unless you set the roles attribute to an asterisk (*), which enables all clients to view the site-map node without first testing access to the URL.
Using Security Trimming with Multiple Site Maps or Providers
You can use multiple site maps together to define the navigation structure for a single Web site. For example, a Web.sitemap file is similar to a Web.config file because it can be split up and placed in different folders.
Site maps are linked to each other by referencing a child site-map file or provider in the siteMapFile or provider attribute of a SiteMapNode [ http://msdn.microsoft.com/en-us/library/system.web.sitemapnode.aspx ] object in the parent site map.
The following code example illustrates a site-map node that references another site map.
<?xml version="1.0" encoding="utf-8" ?> |
<siteMap> |
API Members Affected by Security Trimming
You can use navigation controls to add site navigation to your pages with little or no code, but you can also work with site navigation programmatically. When your Web application runs, ASP.NET exposes a SiteMap [ http://msdn.microsoft.com/en-us/library/system.web.sitemap.aspx ] object that reflects the site-map structure. All of the members of the SiteMap [ http://msdn.microsoft.com/en-us/library/system.web.sitemap.aspx ] object are static. The SiteMap [ http://msdn.microsoft.com/en-us/library/system.web.sitemap.aspx ] object, in turn, exposes a collection of SiteMapNode [ http://msdn.microsoft.com/en-us/library/system.web.sitemapnode.aspx ] objects that contain properties for each node in the map. This is because, when you use the SiteMapPath [ http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.sitemappath.aspx ] control, the control works with the SiteMap [ http://msdn.microsoft.com/en-us/library/system.web.sitemap.aspx ] and SiteMapNode [ http://msdn.microsoft.com/en-us/library/system.web.sitemapnode.aspx ] objects to render the appropriate links automatically.
You can use the SiteMap [ http://msdn.microsoft.com/en-us/library/system.web.sitemap.aspx ] , SiteMapNode [ http://msdn.microsoft.com/en-us/library/system.web.sitemapnode.aspx ] , and SiteMapProvider [ http://msdn.microsoft.com/en-us/library/system.web.sitemapprovider.aspx ] objects in your own code to traverse the site-map structure or create a custom control to display site-map data. You cannot write to the site map, but you can alter site-map nodes in the instance of the object. For more information, see How to: Programmatically Modify Site-Map Nodes in Memory [ http://msdn.microsoft.com/en-us/library/ms178425.aspx ] or How to: Programmatically Enumerate Site-Map Nodes [ http://msdn.microsoft.com/en-us/library/ms178424.aspx ] .
ASP.NET uses the default site-map provider, XmlSiteMapProvider [ http://msdn.microsoft.com/en-us/library/system.web.xmlsitemapprovider.aspx ] , to read the Web.sitemap file. If you want to store site-map information in a location other than the site-map file, you can create your own site-map provider and configure your application to call the custom provider. The site-map provider is configured in the Web.config file. When the application runs, ASP.NET will invoke your provider, which can retrieve site-map information as needed. ASP.NET then creates and populates the SiteMapNode [ http://msdn.microsoft.com/en-us/library/system.web.sitemapnode.aspx ] objects based on the information that your provider returns. These objects can be programmatically accessed by using the SiteMap [ http://msdn.microsoft.com/en-us/library/system.web.sitemap.aspx ] class. For more information, see Implementing ASP.NET Site-Map Providers [ http://msdn.microsoft.com/en-us/library/ms178431.aspx ] .
Security Note: |
---|
|
When enabled, security trimming affects the behavior of some of the members in the SiteMap [ http://msdn.microsoft.com/en-us/library/system.web.sitemap.aspx ] , SiteMapNode [ http://msdn.microsoft.com/en-us/library/system.web.sitemapnode.aspx ] , and SiteMapNodeCollection [ http://msdn.microsoft.com/en-us/library/system.web.sitemapnodecollection.aspx ] classes. When using these classes, you will see the following behavior:
A null is returned by a site navigation API member if it attempts to reference a site-map node that the user does not have the security rights to see. For example, the CurrentNode [ http://msdn.microsoft.com/en-us/library/system.web.sitemap.currentnode.aspx ] , NextSibling [ http://msdn.microsoft.com/en-us/library/system.web.sitemapnode.nextsibling.aspx ] , ParentNode [ http://msdn.microsoft.com/en-us/library/system.web.sitemapnode.parentnode.aspx ] , and PreviousSibling [ http://msdn.microsoft.com/en-us/library/system.web.sitemapnode.previoussibling.aspx ] properties will return a null if the properties attempt to return a site-map node that is restricted.
If a site navigation API member needs to traverse the tree of site-map nodes, any site-map node that the user is not allowed to see is excluded from the traversal. For example, when the ChildNodes [ http://msdn.microsoft.com/en-us/library/system.web.sitemapnode.childnodes.aspx ] method runs, the collection of nodes is filtered to include only those nodes that the user is allowed to see. In the case of API members that need to keep track of node paths, such as the Clone [ http://msdn.microsoft.com/en-us/library/system.web.sitemapnode.clone.aspx ] or IsDescendantOf [ http://msdn.microsoft.com/en-us/library/system.web.sitemapnode.isdescendantof.aspx ] methods, the paths end at restricted nodes. This can result in cloning operations returning a reduced number of nodes. It can also result in the IsDescendantOf [ http://msdn.microsoft.com/en-us/library/system.web.sitemapnode.isdescendantof.aspx ] method returning a value of false even though structurally a node might actually be a descendant of the requested node.
An InvalidOperationException [ http://msdn.microsoft.com/en-us/library/system.invalidoperationexception.aspx ] exception is returned if a site navigation API member references a root node that the user does not have the security rights to see. Only the root node of the root provider needs to be accessible to all users, which prevents an exception from being thrown when first obtaining the SiteMap [ http://msdn.microsoft.com/en-us/library/system.web.sitemap.aspx ] object.
A ConfigurationException [ http://msdn.microsoft.com/en-us/library/system.configuration.configurationexception.aspx ] exception is thrown if a SiteMapNode [ http://msdn.microsoft.com/en-us/library/system.web.sitemapnode.aspx ] object references another site-map file or provider incorrectly.
Note: |
---|
|
Tasks
Concepts
Other Resources
Tags:
No comments:
Post a Comment