Something about user access control or security control design

Below is a few strategy to implement the user access control or the security feature in your application.

1. The simplest design will be user name + password and stores these information in a database table. No control over the feature accessibility.
2. One level harder will be using one security "action" to treat as one permission. And one security action represent a menu option, button, input field, display field or a process to be executed. This design requires 1 user class and a collection of permitted/allowed security actions. So, you need two database tables to stores the information. For example, user A allows issuing and editing invoice but not deleting any invoice. In this case, you will have 3 allowed actions (or record) for user A.
3. In case you feel that having one security action mapping to the feature is cumbersome and require lots of hard space, you may consider adding a flag field in the security action. For example, "Invoice" action will have 3 flags: issue, edit and delete where the "flag" is in BIT data type (in MSSQL database). If the flag value is "1" means permitted and "0" means not permitted.
4. Some applications requires another level of sophistication - that is using "user level" in conjunction with the security actions.
5. Another kind of implementation is to have write level (0-10) and read level (0-10). Both values are use in conjunction with the menu option and input fields. For example, the credit limit field for the customer has read level of "5" and write level of "8". If the user's read level is "5" and the user will be able to view the credit limit field. If the user's write level is also "5", then, this credit limit value will be disabled from editing. 

So, which one is better? It's all depend on your need. As for us, we prefer #2 due to easier to implement and future enhancement. It's also very easy to cater for changes.

Let's assume that you read the previous article, the CUser class will have a CanAccess() method which returns true or false. The application should check the result of this method before performing the process/action whereas CUser class.

Different flavor of CanAccess()

• bool CanAccess(Guid action_id)
• bool CanAccess(Guid action_id, PermissionEnum permission) [PermissionEnum {insert, update, delete, select]
• bool CanAccess(Guid action_id, int user_level)
• bool CanAccess(int read_level, int write_level)

Reusable class - user access control

This is another important area in the systems and it is reusable as long as the design is generic to cover all possible combination.

Basically, it should meet the following requirements:

• Security control - allows user to logon to the system and verify their user name and password.
• Access permission - permission could be controlled by menu level, screen level and field level (whether the field is show/hidden or enable/disable).
• User access log - this is compulsory for audit purpose and also the alert.
• Access deny alert - upon hitting certain number of invalid user name or password, the system should generate alert and email it to the system administrator.
• Password policy - you may consider to implement minimum password length and password complexity.
• Allow supervisor overriding - this can be useful when the current user does not have permission to access certain feature (such as edit customer address) but requires to do so.
• In case the system is a web base system, it should store the browser type and visitor IP address for audit purpose.

 You need the following classes to support the above mentioned requirements:

1. CUser - this class stores the user information such as user name, password, email address, etc.
2. CAction - this class stores all the permissions (or features) for the system.
3. CUserAccessLog - this class responsible for keeping track the user login and logout activities.
4. CLog - this class (which has been discussed in previous article) which is responsible for storing the audit information such as which "action" (or "featuer") the user has clicked.

For the detailed implementation, you might have work it out by yourself.

Reusable class - System log - the information for troubleshooting

In our system design, we are trapping all the exceptions that raised up at runtime and store it into a central database. This allows us to provide faster response time in fixing the error before the user complains. I know many people will ask why there is an error and why it was not catch at the development or testing phase. The answer is simple, we are not developing standard package. Almost all projects come with different requirements except for the "infrastructure" (such as the security, application log, etc).

To log down the exception, this error logging process should done in a very short time so that it won't affect the system performance or other processes. This can be achieve by saving the exception using a different thread.

In our system logging class, we have the following methods:

• AppendLog - this save the log as "audit log".
• AppendError - this save the exception and the failure point as "error".
• AppendWarning - this save the log as "warning" and it is very useful when the system setting is missing or misconfigure.

To track the failure point, refer to System.Diagnostics.StackTrace class.
To save the log information in another thread, refer to System.Threading.ThreadPool.

Our application log table design:

http://sqllauhw2000.blogspot.com/2012/07/you-need-application-log-for-your.html

Executing a process periodically in Windows

There are many types of application running in an enterprise. One of it is called the "nightly job" (i.e., the job that runs periodically) which is running on every night. On the other hand, some of the jobs is running hourly, weekly or monthly.

In our experience, the main issue in running a process periodically is that "schedule" itself. Consider this:

• The simplest schedule job - run the job every night.
• Run the job once for every hour, week, month or year.
• Run the job once for every hour, week, month or year between 10AM to 6PM.
• Run the job on every Monday, hourly between 10AM to 6PM.

This is complicated and requires lots of testing if you are creating your scheduler program. Instead, the better way is to utilized the Task Scheduler that comes with Windows. This is what you have paid for.

Below is the screen snapshot of where you can find the Task Scheduler.

Below are a few ways to execute a job/process periodically in Windows:

1. Develop a Windows Service - add a System.Threading.Timer class and execute the callback periodically. With Timer class, it is able to run the process repeated in the same interval. If you want to run the next callback in different timing, you will have to calculate the interval and call Change() which will be complicated (depends on your need). Another problem that might arise is how to include the dependencies (or DLL)? For example, you need to generate daily report in PDF format and email it to the bosses.
2. Develop a program (.EXE) and schedule it in the Windows Task Scheduler - this is simple and clear cut. With this option, it solves the scheduling problem. But, it does not solve the dependencies problem as mentioned above.
3. Develop a web page which execute the process in a different thread and schedule it in the Windows Task scheduler - another requirement for this option is that it requires a small program which will call the URL (using System.Net.HttpWebRequest class) and pass the URL as the command line parameter. This solves the scheduling complexity (which handles by the Windows Task Scheudler) and also the dependencies (where all the business processes/rules are stay in the ASP.NET website). Of course, if the business processes/rules were in the Windows Client EXE, you will have no choice but fall back to strategy #2 as mentioned above.

Reusable custom web control

When you are building web application, blog site, forum, shopping cart, etc, often, there are some information in "div" will be reuse throughout the website or reused in selected pages. To avoid writing the HTML tag again and again, you may consider using the custom web control.

To create custom web control, right click on your web project and choose Add New Item. Then, choose Web User Control (i.e., System.Web.UI.UserControl class). Web user control is able to utilize the HTML designer in Visual Studio. So, you will be able to complete the design in a shorter time.

Another way to create custom control is to writing codes by declaring a new control which inherits from CompositeControl or WebControl. But it does not support any visual designer. The biggest challenge is for the graphic designer to touch up the design in C#/VB.Net code because they are not the programmer.

Advantage of using UserControl:

• Easily separate the JavaScript from the web page.
• Easily moving the control around the web page.
• Easier to test the custom web control.
• Easier to share the same control in different design style with other projects.
• Easier to maintain the design with or without using CSS file.
• Reduce the complication of HTML tags within a page.

When to use it?

• You have to display "modal dialogue" box in the page which requires JQuery dialog. This dialog requires a "div" for the dialog and also contains the many data entry fields.
• The "compulsory" aster rick marker in red color.
• The "last updates", "news" or "events" section.
• The banner for header and footer.
• Application menu.

Should I develop a custom control or just add it to the form

The definition of "reusable control":

• The control will be reused in many areas in the same project - for example, "customer group" drop down list which can be reused in many screens within the same project.
• The control will be used more than once in a project and also useful in other project - for example, DevExpress has developed xtraReport which can be reuse in many projects.
• The control will be used only once in a project and also useful in other project - for example, you have developed a "main menu" control which reads the menu options from XML file.

In order to speed up the development, testing, implementation and maintenance, you are advisable to come out with a custom control and then drag it into other custom control or Form.

Tricks for using custom control:

• Drag the custom control on a MDI child Form - in this case, you control will always sit inside the MDI parent window.
• Drag the same custom control on a non-MDI child Form - in this case, you can shown the control modally.
• Drag the same custom control into a Tab page control and show it in any Form - now, you custom control will be act like a tab page.
• Another rare situation is that you instantiate this custom control at runtime and position it to the appropriate location. By doing this, you don't have to mess up the parent control/Form. The coding will be very clean and precise.

Designing reusable control Part 2 - designing composite control

Of course, when things are simple, you can always try to look for the best available control and create a child class from it. But, in real life, you won't always get the easiest job. This is the time that you need more than inheritance from the object oriented programming.. the composite control.

Steps to develop a composite control using UserControl

1. Right click on the project.
2. Choose Add new item.
3. Select UserControl.
4. Then, drag the necessary controls from the common control section into the UserControl that you have just added.
5. Start writing some codes for this new UserControl. Of course, the most important will be loading data, validating user input and saving data. Another piece of code that is helpful is called "RefreshUI" which is responsible for controlling what should be hide or show on the screen base on the parent form/control. You might consider to add this method into your UserControl.

As simple as that, you have a composite control. Well, you can google for tutorial on the detailed steps with nice print screen. Sorry, I'm not going to repeat it. What I plan to do is to explain when do we need this?

From my experience, it seems many developers especially fresh graduate they "know" UserControl but "never use" it. Below is some example from live experience:

• My customer asked me to develop an attendance grid which displays all the check-in guests. So, I started with "attendance item" control which displays the guest's photo + name. Then, I developed another control call "attendance grid". Finally, I developed "attendance" control which relies on both attendance item and attendance grid.
• The situation gets complicated when you have domestic guests and international guests. These guests are using different "identity card" and the identity number are handled in different way. So, we develop a UserControl which is able to capture both domestic and international identity  number. This control is then reused in many of the screens.
• We also develop a composite control to show the necessary options for the user for generating report.
• Application menu is the composite control that will be reused in all projects.