On this page...
Archive
| July, 2011 (4) |
| September, 2010 (1) |
| May, 2010 (2) |
| April, 2010 (2) |
| March, 2010 (3) |
| February, 2010 (5) |
| November, 2009 (4) |
| October, 2009 (2) |
| October, 2008 (2) |
| July, 2008 (3) |
| June, 2008 (4) |
| April, 2008 (1) |
| January, 2007 (3) |
| December, 2006 (2) |
| October, 2006 (1) |
| September, 2006 (1) |
| August, 2006 (4) |
| July, 2006 (2) |
Categories
Archives
| | Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|
| 29 | 30 | 31 | 1 | 2 | 3 | 4 | | 5 | 6 | 7 | 8 | 9 | 10 | 11 | | 12 | 13 | 14 | 15 | 16 | 17 | 18 | | 19 | 20 | 21 | 22 | 23 | 24 | 25 | | 26 | 27 | 28 | 29 | 1 | 2 | 3 | | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
Links
|
Category:
As a set of syntactic constructions that allows you to limit access to code snippets for different groups of users meets the mentioned requirements, the permission entity can be used. What is the difference between the permission and the role?
A role is a grouping element in the structure of interaction “user – action.” That is why roles are strongly linked to the notion of “user” at the semantic and structural levels. Consequently, an entity that can group and abstract, but which is linked to the notion of “action,” i.e., to the content management system, is necessary. A permission is a separating element that adds a new level of abstraction to the structure of interaction.
From the standpoint of the developer, the functions of permissions are:
- To group the system capacities in frames of acceptable user actions.
- To allow the creation of formalized descriptions semantically linked to a specific set of the opportunities within the content management system.
- To bind code access to the initial code.
- To provide objects in a form that allows you to implement structure interactions with roles and separate users of the content management system.
Now let’s examine the “permission” entity in more detail. A permission usually has a name that is lexically and semantically linked to some action of the system. For example, a user who has «AddUserModulePermission» can add user modules. However, a name is not enough to provide the unique identification. If there are several types of user modules in the system, a conflict of names may occur.
As mentioned above, content management system consists of a set of continuously updated, added and deled blocks. That is why assuming the uniqueness of permission names is incorrect. To provide unique permissions throughout the entire system, global uniqueness identifiers (GUID) are used. Another benefit of using GUIDs is the ease of manipulating them in the database management systems.
To bind code access permissions to the initial code of the system components, the following entities are required:
- Classes that allow you to use an imperative programming style;
- Attributes that allow you to use a declarative programming style for code access security.
The classes AllowCMSPermission and DenyCMSPermission that implement the IPermission interface are used to apply an imperative programming style. Implementation of the interface is necessary for all classes that are the part of the security system and are used to limit access to the code parts.
A unique permission identifier is passed to the class constructor when the class is created. IPermission.Demand() is a key interface method in using a created class instance. A unique permission identifier is passed to the class constructor when the class is created. IPermission.Demand() is a key interface method in using a created class instance. When the method is called, a user is verified for the availability or absence of one of the permissions. This permission is the one whose identifier (the one described as “A unique permission identifier is passed”) was passed as a parameter while creating the class.
If the user, or user role, does not meet the conditions of permission availability, SecurityException is activated. These classes are opposites of each other. AllowCMSPermission approves users who have the required permission, while DenyCMSPermission approves users who do not have the permission.
The two class attributes, AllowCMSPermissionAttribute and DenyCMSPermissionAttribute, are used for a declarative programming style. They are derived from the CodeAccessSecurityAttribute class, which has a very useful characteristic in terms of a security system. Before the method call, the CLR checks whether the method is linked to the attribute derived from the CodeAccessSecurityAttribute class. If it is, the method CodeAccessSecurityAttribute.CreatePermission(), which returns a link to the class that implements IPermission interface, is called. Then, CLR calls the method Demand(). Of course, these attribute classes also implement the opposite conditions of the permission availability. Another useful characteristic of these attributes is the ability to combine them. If it is necessary for a user who has at least one permission to call a method, it is enough to list the attributes with the identifiers of the necessary permissions before the method declaration.
Finally, the ability to check the set of permissions associated with a particular user is necessary. This ability is provided by the extended implementation of the IPrincipal interface. IPrincipal is a standard mechanism for retrieving information about the user in ASP.NET and WinForms. That is why we drew from it and created the new method ICMSPrincipal.HasPermission(). The unique permission identifier is passed as a parameter, and the Boolean that defines whether the user has the permission or not is returned.
Compared to the traditional authorization role model, the permission-based model may look more bulky. But it works perfectly when software development outsourcing is involved. The permission-based model is used as an extension to the existing role model when the capacity of the role model is not enough for effective authorization system management.
There are limitations in the role model of ASP.NET authorization for content management systems. The problem lies in defining the critical set of roles. Both ways that are available to developers have their own drawback that can be easily avoided when the security system administrator and the developer are the same person, or they work in the same office. However, if they are spread around the world, as in the case of software development outsourcing, the problem needs a different solution. Let’s take a deeper look at the problem. When a user registers on a Web site, he or she gets identification data – a login and password - that gives access to additional benefits provided by the Web site.From the standpoint of developer, the process of giving benefits to registered users is divided into two sequential steps: authentication and authorization. During the authentication process, the system verifies whether the user is who he claims he is. During the authorization process, the system gives the user permission to do something or have something. The effectiveness of the implementation of these steps is essential for the effectiveness of the entire security system of the Web site. Let’s examine authorization in more detail.During the authorization process, the system matches the user name with a subset of opportunities available to this user on the Web site. This is done with the help of a particular entity that allows you to match the subset of opportunities with several users at once, uniting users on the basis of equal rights. The entity is called a role or a group of users.There is a set of tools for defining the list of additional opportunities for registered users, made available to the ASP.NET developer:- Configuration file (web.config) allows you to limit access at the level of subdirectories and files by using the configuration sections <authorization> and <location>;
- PrincipalPermissionAttribute allows you to limit access at the level of the method call or properties of classes;
- PrincipalPermission class allows you to limit access at the level of code snippets within a method or a property;
- IPrincipal interface allows you to limit access to code snippets by using the IPrincipal.IsInRole method call.
Using a variety of tools, the developer places method and attribute calls within a configuration file and Web page code. Names of roles with a defined action are used as the input parameters. It is also necessary to have a list of all the roles supported by the system for running a security system. The type of repository does not matter in this case. Here is the problem. Which of the two sets of roles is critical? The one that is scattered in the code as the input parameters, or the one that is in the repository of roles? In the first case, the security system administrator has to scan the code before filling in the repository of roles to catch the names of all roles used as the input parameters. In the second case, developer must be sure that the names of roles are consistent throughout the lifetime of the system because, otherwise, it will be impossible to change or delete the names of roles.This is not a problem when the security system administrator and the developer are the same person, or they work in the same office. However, if they are spread around the world, as in the case of software development outsourcing, it is very difficult or even impossible to make changes in the initial module code. To solve the issue, a set of syntactic constructions that allows you to limit access to code snippets for different groups of users is necessary. This set should meet the following requirements:- Ensure the independence of the module developer from the security system administrator in defining the user groups with limited access to the code snippets module.
- Have a mechanism for the export of a set of user groups involved in the system of restrictions for a specific module. This allows the administrator of the security system of the Web site to match the existing set of roles with the system of restrictions for a specific module.
- Have a unique namespace for a specific module of the content management system of the Web site.
- Have backward compatibility with the existing role model for authorization.
- Ensure an opportunity for a declarative programming style.
In the next blog post, a solution where the permission-based model is used will be presented.
|