Databases Reference
In-Depth Information
public override bool CanRead(IPrincipal principal)
{
if (this.Name == “Products”) return true;
if (this.Name == “Categories”) return true;
return principal.IsInRole(“Employee”);
}
Hard-coding the authorization rules in the permission methods is straightforward and
helps consolidate security settings. It usually produces a much more compact definition of
authorization rules than the
Web.config
-based approach (how much more depends on
you code formatting style, of course). On the other hand, hard-coding the rules, by defini-
tion, means that they cannot be changed at run time. And perhaps the more important
drawback is that the size and complexity of the permission methods also continue to grow
as the size of your entity model increases.
To allow changing the authorization rules at run time, you could define much more gran-
ular, action-level roles for each entity and require a user to be in a corresponding role to
perform the action. For example, the Product entity could have corresponding roles called
CanDeleteProducts
,
CanInsertProducts
,
CanReadProducts
, and
CanUpdateProducts
. With
similar roles defined for all other entities, implementation of the
CanRead
and other
methods in the
MetaTable
descendant could be as simple as the one shown here:
public override bool CanRead(IPrincipal principal)
{
return principal.IsInRole(“CanRead” + this.Name);
}
By defining granular, action-level roles, you can make the permission methods simpler,
but only at the cost of having to manage more roles at run time. If you are using the
built-in ASP.NET web configuration tool, the large number of roles required with this
approach is usually too much to handle. If runtime configuration of the authorization
rules is required in your application, you might want to consider using the Microsoft
Authorization Manager (AzMan), which allows you to define entity actions as low-level
“operations” instead of the high-level roles. AzMan provides a powerful configuration
console that allows mapping operations to roles and assigning roles to individual users or
groups.
Some applications have their own authentication and authorization systems, often with
user information and their access permissions stored in a database. If that is the case in
your application, you can also reuse your existing security system when implementing the
MetaTable
permission methods. Keep in mind, however, that these methods can be called
multiple times for each page request. It is important to cache the authorization rules in
memory and avoid hitting the database every time to make rule evaluation as fast as
possible.
