-Satya Prakash
Introduction:
Building a secure application is not as simple as adding a password protected login screen. This article describes a collection of patterns to be used when dealing with the application security. In this article I am going to discuss about Single Access Point, Check point, Roles, Session, Limited View and Full View with Errors as these are widely used across the IT industry.
Single Access Point:
An army base provides a prime example of a secure location. Army personnel are allowed in while spies and reporters must be kept out. If the base has many entrances, it will be much difficult and expensive to guard each of them. Security is easier to guarantee when everyone must pass through a single guard station.
A security model is difficult to validate when it has multiple “front doors”, “back doors” and “side doors” for entering the application. The application will need a way to log a user into the system, to set up what the user can and can’t do and to integrate with other security modules from systems that will be interacting with. Single Access Point is a right solution for this problem by providing a secure place to validate users and collect global information needed about users who need to start using the application. This information is passed through some sort of Check Point that verifies the information. A Session is then created based upon the configuration settings and user’s access privileges. This Session is used to keep track of the global information that deals with the user’s current interaction with the application. When opening up any sub-application, requests are forwarded through the Check Point for handling any problems and validations.
Check Point:
Army Personnel working at a base have a security badge which is checked by the guard at front gate. They also have keys which will allow them to enter only areas in which they are authorized. No one is allowed in without a badge. Anyone who tried to enter a restricted area without clearance is dealt with severely.
At the Single Access Point, Checks must be made to verify that a user is permissible. Unfortunately, these checks could make getting into wrong password. While users may often mistype their passwords, frequent, consecutive failures without success could indicate that someone is trying to guess a password and break into the application. Application security should be designed in such a way that it must allow occasional mistakes while doing its best to keep a hacker out. Being a developer we could design many checks to determine if a user is trying to break into the system or is just making common mistakes in an efficient way. Check Point helps out with this by organizing these checks. The solution is Make an object that encapsulates the algorithm for the organization’s security policy. This object keeps track of how many exceptions should happen and decides what actions need to be taken based on the severity of the security violation. Any security check can be made part of the Check Point Algorithm, from password checks to authorization checks. In most of the systems, this pattern is separated into two conceptual parts: authentication and authorization. The combination of Single Access Point and Check Point provides authentication to the system and the combination of Check Point and Roles (user’s Role) provides proper authorization to the system.
Roles:
Every army base has commander. This commander gives the order if the base is to be shut down or brought to full alert status. These commands are privileges of the office of the commander, not of the particular person who holds that position. When the base commander is transferred or retires, a new person holds the position of base commander. “Base Commander” is that person’s Role.
Ensuring security can be more complicated in multi-user applications. Users have different areas of the application that they can see, can change, and control. When the number of users is large, the security permissions for users often fall into several categories like user’s job titles, experience or department. Ultimately, the administrator will struggle with managing the security profiles for large number of users. The administrator needs an easier way to manage permissions. The best way to achieve this is Create one or more role objects that define the permissions and access rights on different actions that group of users should have.
When a user logs in, he is assigned a set of privileges that specify what data is accessible and which parts of the application can be activated. From an administrator’s standpoint this user-privilege relationship is M-to-N, making it difficult to manage.
Introducing Roles creates two new relationships that must be managed: user-role and role-privilege. These new relationships can help managing security easier. When the privileges of a job title changes, then that role-privilege relationship can be edited directly. When a user gets a promotion, the user-role relationship can be changed instead of checking each user-privilege relationship for accuracy.
Session:
Army personnel’s activities are tracked while they are in high-security Defense bases. Their entry and exit are logged. Their badges must be worn at all times to show they are only where they are supposed to be. Security personnel inside the base can assume personnel with a badge have been checked thoroughly at the base entrance. Therefore they only have to perform minimal checks before allowing them into a restricted area. Many people will be working in a base at the same time. Each security badge (similar to Session Id of an application) uniquely identifies who that person is and what they can do. It also tracks what the carrier of the badge has been doing.
Secure applications need to keep track of global information used throughout the application such as username, roles and their respective privileges. To achieve this Create a Session object which holds all the variables that needs to be shared across many objects. This session object is then passed across the application so that any objects which need any of its values can access easily. Certain user information is used throughout the system. Some of this information is security related, such as the user’s role and privileges. A Session object is a good way for sharing this global information. This object can be passed around application and used as needed.
Full View With Errors:
Once army personnel allowed on an army base he or she could go to any building on the base. In effect, the officer has a full view of the buildings on the base. If the personnel try to enter a restricted area without proper clearance, either someone would stop them and say that they are not allowed in the restricted area or alarm would sound and guards would stop them.
GUI applications often provide multiple ways to view data. Users can dynamically choose which view on which data they want. When the application has multiple views, the developer must always be concerned with which operations are legal based on the current state of the application and the privileges of the user.
The conditional code for determining whether an operation is legal can be very complicated and difficult to test.
The solution for this is Design the system in such a way that all users can see everything of the system. When a user tries to perform any operation, check if it is valid. Notify the user with an error message when they perform illegal operations. This pattern fits best in applications where a user can perform almost any operation as user will be notified with very less number of error messages. Oracle Database is the best example to explain this pattern. When you access Oracle Database through SQL Plus, you can execute any command. However if you try to access data on which you don’t have privileges, then an appropriate error message will be shown.
Limited View:
When any higher official of army visits a base, he is given an escorted tour. Before arrival, a tour would be set up. Some areas of the base, such as the missile’s target range would be designed as unsafe and other might be designated top secret. The tour will be predesigned to give him a limited view of the base relevant to his security clearance.
Graphical applications often provide many ways to view data. Users can dynamically choose which view on which data they want. When an application has multiple views, the developer must always be concerned with which operations are legal given the current state of the application and the privileges of the user. The conditional code for determining whether an operation is legal can be very complicated and difficult to test. By limiting the view to what the user has access to, conditional code can be avoided. The solution is only let the users see what they have access to. When the application starts up, the user will have some Role or the application will default to some view. Base upon this Role, the system will only allow the user to select items that the current Role allows. If the user can not edit the data, then do not present the user with these options through menus or buttons.
No comments:
Post a Comment