Product Shootout - Security Systems for Clarion for Windows

by Tom Hebenstreit, Review Editor

Published 1997-09-01    Printer-friendly version

Welcome to the Clarion Online Security System shootout! This month, we will be looking at not one, not two, but THREE full featured security systems designed for Clarion for Windows. They are:

• DAS_Security from Tinman Development Corp
• SecWin from CapeSoft
• SuperSecurity from Boxsoft Development

This overview will cover some basic security concepts, what to look for when evaluating security systems, describe how we tested the systems, and conclude with a side by side comparison of the basic feature lists of the three packages. So, without further ado, let's get on with it!

Security - just what is it?

A warm fuzzy blanket, right? Maybe an overflowing bank account?

Well, both of those are nice – but in this case, for the people or companies who purchase your software, it means protecting their precious data by giving them control over who has access to it. This doesn't just mean protection from competitors or hackers; it also means being able to place 'need to know' type restrictions on their own employees in regards to sensitive information, as well as preventing users from accessing portions of your programs which are not directly related to their specific job functions.

How does a security system work?

In the simplest terms, a security system does two things:

1. It asks the user "Who are you?"
2. It then alters the behavior of the program based upon the answer to question 1.

That's it. Pretty tough, eh? In essence, any time a user tries to do something that has been designated as needing security, your program will ask the security system something like: "Bob Jones wants to access the Employee Salary browse. Should I let him?" If it answers 'Yes', Bob simply sees the browse pop up. If he isn't authorized, your system can do something like beeping or displaying an 'Access Denied' message. Exactly what it does in the case of a 'No' response is up to you or your users (depending on how flexible the security system is), but the end result is the same: Bob does not get to see the salary browse.

Security like this can be applied at many levels, from the application level (is Bob even allowed to run the application?) down to the individual control level (does Bob get to see the Salary field when he edits a User record?).

What was that name again?

So how does the program know that it is Bob using the program and not Sally? The usual method is to have the program ask the user who they are whenever they try to run the program (a process normally called login or logging in). Once they have identified themselves, the program will automatically check with the security system and hide, disable or expose menu items, buttons and controls as needed. In a well-designed program, the login screen should be the only time the user is even aware of the security system. For example, if they are not authorized to use your payroll options, the security system should simply hide them – out of sight, out of mind and, most importantly, out of temptation. This is vastly preferable to a system that lets them click on the payroll options only to tell them to go away (the infamous 'Access Denied' type of message).

There are no hard and fast rules as to when and where users login, though. Programs can have multiple logins for different areas, or only require logging in for special functions (such as, say, archiving data files). Programs that need extra security may require an option to let users lock their screens when they leave their desks, or to have the ability to log the user out of the program after a certain period of inactivity. Options like these help the system to prevent unauthorized users from gaining access to protected functions and data via an unattended (but logged in) PC.

Leaving footprints

Another important function of many security systems is to provide the option to have the system keep track of who did what while in your program (often called an audit trail or activity logging). That way, you can always find out who gave Pat the mail room clerk that $5,000 a month raise, or who deleted all the records for your biggest customer.…

Better systems let you dictate exactly what actions you want to have logged (pay raises, for example), and let you add messages of your own to the log when desired. They also should include some method of reviewing the logs, and for discarding old transactions. Log files have a tendency to grow like weeds, and can easily grow HUGE (over 50 megabytes, in one case) with years of "Fred logged in, Fred logged out, Sue logged in, Sue logged out" type transactions.

An additional item to check for is how the logs are physically stored. A security log stored in an ASCII file, for example, is only secure as long as none of your users know how to use Notepad or a word processor. Not very likely, is it? Look for log files that can be encrypted (scrambled) if you need maximum security.

The big picture

Where this all comes together is in the logical design of your security system. The physical implementation might be very simple (run a wizard, add some templates), but the logical design dictates exactly how the security functions contained in those templates will be used. It is here where you choose just which of the various security methods you (and your users) are going to use. Each of the packages under review offers a number of different methods (and names for those methods), but they all break down into two basic security philosophies:

1. Control where the user can go – the idea here is to block the user from certain procedures or areas of the program, but to not really care what they do in the places they are allowed to access. For example, if you are granted access to payroll, you can do anything there (add, change, delete, etc.).
2. Control what the user can do – this method assigns rights not to specific places, but to the basic actions they will be allowed to perform. An example of this method would be that a low-level clerk cannot delete records, only add them. It doesn't try to control where that clerk goes, just what can be done once there.

Which is better? The typical answer would be: Either or both! It is not uncommon to see systems where both methods are employed, e.g., you are a clerk, you have access to accounts receivable, but not accounts payable. Within accounts receivable, you can add records but not delete them. The downside is that these hybrid systems can be much more difficult to administer due to the increased number of options and the need to specify multiple levels of access as well as basic access authorities.

Some security systems require that these security access methods and logic be hard-coded into your application, but by now you can see that it is often much more desirable to have a system which allows your users to dynamically control how much and where security is applied. Less job security for you maybe, but definitely better programming practice.

As for exactly how much security is needed, that is up to you and your customer. Remember, though, that a well-designed security system should strive to achieve a good balance between control and invisibility. Your customers will not appreciate a system that is constantly demanding passwords or telling them to get lost if they are not authorized to use a function.

So, what does this mean for my applications?

For you as a developer, it means adding a framework for those access control methods to your applications, and providing customers with a way to setup and administer their users within that framework.

You see, unlike most CW third party templates and tools (which are designed to be used only by the developer when building an application), a security system consists of two separate but interrelated components. The first is the set of templates, procedures and functions, which you as a developer use to implement the nuts and bolts of security in your application.

The second component is generally another application or program, developed by the authors of the security package, which gives your customers a way to setup and administer the security system on a day to day basis.

This brings up an important consideration: how much can you do to match the look of the security screens to your own applications carefully designed look and feel? (Matching fonts and colors, for example.) Remember, to the user it is all YOUR product, and it's up to you to ensure that the pieces fit together..

So, you may have to integrate the security system into your application, but they have to use it, which brings us to the next point….

Fitting round users into square holes

OK, now we know how security works, but who is the one to actually set the system up and tell it about Bob and Sally and what they can or cannot do? Enter the system administrator, a big name for the often thankless job of the person who will enter Bob and Sally (and everyone else) into the security system, assign each of them passwords and access rights, and generally have control over the entire system. Ninety-nine percent of the time, that person is not you, the developer, but rather is one of your users, and from that user's point of view, the three most important criteria for a security system are:

Does it work?

Pretty basic requirement. It has to do what you say it does.

Is it easy to administer?

This is a killer point. It doesn't matter how powerful the security system is if it gives the system administrator the shudders every time s/he needs to add a user or change access rights. Let's say, for example, that you are the system administrator at Big Time, Inc., and have over 100 clerks doing data entry. The boss decrees that clerks should no longer be able to print reports, so you need to change their access rights. But…the security system makes you change the rights for each clerk individually, one at a time. Ouch. Can you say "unhappy customer"?

To avoid this type of problem, look for systems that support combining users together in Groups. Security levels and access are not assigned directly to each user, but to a Group (or category) of user. Users belong to one or more Groups, and it is the Group that gives them access. In the case of our poor administrator at Big Time, the task could be reduced to simply changing the access rights for the Group called 'clerks' to remove the right to print reports. One simple operation. One happy administrator.

Is it flexible enough to let us do things the way we want to do them?

For example, Company A wants to identify users with a User ID, while company B is going to use a Payroll Number. Will the security system let them use their own terminology on the security screens? Can your customers create new categories of users? Can they change their minds, adding or removing access restrictions without needing you to modify the program itself?

From the programming standpoint, your question should be: "How hard will it be for me to get the security system to do the above?" Keep in mind that the security administration program is generally designed and written by the authors of the package (and you may not have the source code).

The moral of this story is to be sure that both components of your security package work the way you (and your customers) need them to, and that awkwardness in security administration doesn't tarnish the fine reputation of that incredibly sleek and polished application which you just released!

How did we do the testing?

OK, enough theory, let's get down to the nitty-gritty.

Testing for all of the reviews was done using the 'Personnel' sample application that was provided by TopSpeed on the CW 2.003 CD. This type of application is a prime candidate for security in the real world, in that it contains potentially sensitive information about employee salaries. If you haven't checked it out already, you can find the app in your '\CW20\Examples\Personel' directory. (Note that this assumes you have: A) installed CW 2.003, and B), you chose to install the sample applications from the CD.)

To make it as easy as possible to compare the three products, each reviewer was given the same list of simple security requirements to implement with their respective packages. In general, those tasks were to create two levels of users, managers and clerks, with the following limitations for clerks: 1) no access to 'Salary' information, 2) they cannot remove (delete) employees and, 3) we hide some information from them on the employees form.

Specifically, each reviewer was requested to:

Programming Tasks (Implementing Security)

• Add the security package to the Personnel app
• Do whatever had to be done for the end user to access administration

Administrative Tasks (Using Security)

• Create two levels of security (manager and clerk)
• Add a manager and two clerks
• Prevent clerk access to the Salary report
• Prevent clerk access to Salary browses (toolbar, menu and employee browse button)
• Limit clerk access for update on the Employee browse (no delete)
• Hide/display fields on a form based on clerk or manager (Only manager sees Date Hired, Job Title and Department)
• Add five more clerks and give them the same rights as the original
• Give all clerks access to a new report
• Login as a 'clerk' and verify that all restrictions are working.

These tasks only cover the basics of a security system, but they should still give you a good feel for how each security package accomplished its stated mission.

And, by the way, did you notice that most of the tasks ended up being administrative?

Side by side (by side)

The following is a brief summary listing some of the more important features offered by the three products under review. Be sure to read the individual reviews for a detailed look at each package, and for contact information on the vendors.

	DAS_Security 2.0 (Beta version) Tinman Dev. Corp.	SecWin 2.7 CapeSoft	SuperSecurity 1.92 Boxsoft Dev.
CW Version	2.x	2.x	1.5x, 2.x
Implementation
Adding to your App	Wizard or Manual	Wizard* or Manual	Manual
Requires Hand Code	No	No	No
User prompt and message changes	Developer	Developer and User	Developer
Can you modify the Administration programs?	Yes, application for Administration program provided	No (application provided for Reg util only)	Yes, applications provided
Tools to help Administration and Setup	Utilities to export application information to Admin program	Utility to create security files	Door and User file edit applications provided
Multi-DLL support	Yes	Yes	Yes
Modifies the CW templates	No	No	No
Uses black-box library	Yes	Yes	No
Documentation
For the Developer	Win Help File	Printable (WRI)	Acrobat PDF
For the End User	Win Help File for Administration Exe (source included)	Printable User Guide (WRI) which you can adapt	None
Administration
How Accessed	Centralized in Exe provided by TDC	Hot key or menu within your Exe	User Edit application
User Grouping	Yes	Yes	No
Security Reports	Yes	No	Yes
User Monitoring
Audit Logs	Yes	No	No
Inactivity Logout	Yes	No	No**
Active User Monitor	Yes	Yes	No**
Other Goodies	Screen lockout, Time of day options	Screen lockout, Program Copy Protection and Registration, Btrieve support, all screens translatable
Price	$199.95	$99*	$99

Notes
* The 16-bit version of SecWin is free (yes, you read right: FREE), but doesn't include the Wizard which automates adding the package to your applications or 32-bit support.
** Boxsoft provides this functionality via separate add-on products.

Support for other versions of CW

If you are using CW 1.5x, you're options are a bit more limited. CapeSoft still offers an older, CW 1.5x compatible version of SecWin (2.6), but it lacks a few new features such as forcing password changes (as well as the most current bug fixes). SuperSecurity is the only product to still directly support 1.5x in the most current version.

As for the upcoming Clarion 4 (C4), all of the vendors have stated that they will be enhancing their products to support it when it is released (or soon thereafter).

Wrapping up

Whew! Lotta stuff to cover, but we are fortunate to have this many great packages to choose from. Bottom line: All of these packages provide the basics of a solid security system, (some provide a lot more) and all of them cost far less than the value of your own time if you had to try and write your own security system. So… check them out!

The Winner...

This was a very tight battle, with two strong contenders for the title. While DAS_Security was better able to perform the assigned tasks, the documentation for DAS_Security was a detriment to its overall standing, as this impacts how quickly the user can get in and use all the nifty features. Super Security received Very Good scores in all categories but one, Technical Support, where it received an Excellent. Since Technical Support for DAS_Security and SecWin were untested, we cannot compare except to say that they could not have scored better than Super Security's Excellent. As we said, a very tight battle. We feel that the balanced quality of Super Security is better for the user (you) than a greater feature set, accompanied by poor documentation. As DAS_Security is in beta, however, the documentation will probably improve before final release. We therefore award the first Clarion Online Editor's Choice award to Super Security. - Jeff Stevens, Clarion Online Editor

Printer-friendly version

Copyright © 1999-2008 by CoveComm Inc. All Rights Reserved. Reproduction in any form without the express written consent of CoveComm Inc., except as described in the subscription agreement, is prohibited.

Clarion Magazine ISSN 1718-9942