AuthorizationRuleProvider

Topics: Web Client Software Factory, User Forum
Jun 14, 2007 at 11:46 PM
We have certain requirements for sitemapnode authorization that are outside the boundary of typical security based authorization. Given the request url either from www.example.com or www.example2.com or www.example.com/clientname we have contextual information about the request that we can derive whether sitemap nodes should be visible. For instance in the clientname example the client has specified allowed interests or products categories for their traffic. So a sitemap node as I see it applies to a product category.

So my question is in the past prior to WCSF and entlib we just subclassed the XmlSitemapProvider and implemented the logic that way. However to utilize the WCSF, it seems to be that it may be easier or more appropriate to subclass the AuthorizationRuleProvider. What would be other recommendations?
Jun 27, 2007 at 2:02 PM
Was there ever a response to this?

I just had the security model for a project turned upside down and need to change the base provider. What is the optimum way to handle it?
Jun 27, 2007 at 2:39 PM
So for now the way we approached the problem to add attributes to the attribute collection when registering the sitemapnode. Then in the databound events in the menu remove the visibility after performing the necessary logic. Not a very elegant solution in my opinion, but for now it will work for us. Ideally I think the menu system could allow for more dynamic options (Visibility, text value, etc) based on rules engine like AuthorizationRuleProvider. So to NOT answer your question I didn't change the base AuthorizationRuleProvider.