This post relates to the purpose of IPrincipal.IsInrole(string role)
A static role is not very useful in a dynamic environment. Instead, authority to perform an action can be dependent upon many other variables based on the state of the internal application and data store. In an application I am converting to ASP.Net 2.0, we need to be able to do Just-in-Time access checks. This should be based on authority to perform an operation, not based on membership of a group in static fashion.
But, I feel like the Role provider is so interwoven throughout the system that I could treat IsInRole() as an actual permission checker.
The string passed to IsInRole() in my custom principal could make a call to an underlying manager that determines whether the user has the authority to perform the action.
In this case, an opertion that requires the ability to "PlaceOrder" could determine that authority just-in-time (and cache the result of each so that subsequent calls during the lifetime of the page do not incur the same db hit again)
So in this case, I could create a standard sitemap and uses the roles attribute to limit the PlaceOrder.aspx page to members of the PlaceOrder "role", so to speak.
Theoretically, I supposed I could call them OrderPlacers and the semantics would remain more true to the notion of Role, but it sounds kind of silly. The main goal is to work within the existing and cohesive API to achieve restriction to content based upon named identifiers.
Any thoughts on this type of scenario?
Thanks