Monday, October 22, 2012

Scaling out your system using web services

There are many different ways to improve the system respond time: one of the strategy is call scaling out. In our system design, we are implementing the "basic modules" (i.e., the system infrastructure) in web service and it is able to achieve this easily.

Web service does not have a huge different from a website. The noticeable different is that it does not have user interface (or web pages) for visitor to access. You may imagine that the web service like a mobile phone station/transmitter which is providing connection to the mobile phone. In .Net, the web service is implemented in ASMX format, WCF (Windows Communication Foundation) or simply ASPX (which returns the data in XML or JSON format).

Now, the best part of web service is not something that will make our solution cool. Instead, it is able to scale out to a server other than the web server (that is hosting the website). In this case, our customer might end up with a web server to host the website, a few web servers that host the web services.

Many programmers argue that web service is slow because of XML SOAP involves in the communication. It's true that web service in ASMX is slow but the visitor won't really feel it because of these communications were made among the web servers which is sitting next to each other. Of course, the web service implemented in XML SOAP is not suitable for real-time application. The real-time application requires low level socket programming and the handling strategy will be different.


Monday, October 15, 2012

Security web service

When you are developing a large scale application, you need a security module that is able to authenticate the users. In our system design, we developed a security web service which is shared among the sub-modules and also reduce the development time.

In .Net, you can achieve this with the technology that you want:
  • Implementing the security service using ASMX/ASHX - this service will be hosted through HTTP/HTTPS.
  • Implementing the security service using WCF - in this case, you will have the choices of different protocols such as TCP, named pipe, etc.
If you are asking why we need to reinvent the wheel when .Net comes already have this security feature for enterprise? The answer is simple: our security web service can be tailored made based on our customer's requirements. We know that not all projects that we are involving requires a complex security service. Some requires a basic login with user name and password only. Some requires the security control upto field on the screen.

Updates on 6th May 2017 - it seems like ASMX or WCF are quite hard to be converted to other programming language/platform. Best is to use ASHX (i.e., generic handler) which has a faster response time due to it's simplicity and  flexibility. It's also easier to port over to other programming language/platform.

Monday, October 8, 2012

Security design consideration for web application

The security problem with web application:

  • Web application is easier to hack as long as you know the URL - this means that some security control must be implemented in the web application.
  • The primary key value of the table is integer data type - this is easier to guess what's next value. For example, "http://myWeb.com/customer.aspx?cust_id=123" and the next record is "http://myWeb.com/customer.aspx?cust_id=124".
  • Session ID - you may rely on the ASP.net session ID or you handle it your own.
  • Deleting record with JavaScript confirmation and then fire AJAX call to the delete action URL - is this secured? Does the delete action page implemented sufficient control?
  • Folder with read & write permission for user uploading file - without limiting the file type that is acceptable by the web application, your website will have a security hole that can be exploited.
  • Audit log should include the browser type, URL referrer and also the user's IP address. Without these information, it will be impossible to track who has accessed which feature/data.
My question is that do you have all your ASPX web page inherit from your custom page class or System.Web.UI.Page class? If you are using the later, then, you are letting your programmer to implement all kinds of security control that might have security loop hole.

Monday, October 1, 2012

Security check point


In Windows client, you can develop a static function call SecurityCheckPoint() that gets the user ID and password. This SecurityCheckPoint() method will be very useful whenever you want the user to re-authenticate before any process start OR you want to get the supervisor authentication.

Well, this can be useful for the web application as well but you need to implement it using JavaScript that show a modal dialog and AJAX calls for authentication.

Tuesday, September 25, 2012

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)

Thursday, September 20, 2012

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.

Monday, September 3, 2012

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