Base One's architecture is designed for building efficient database applications with demanding security requirements. Thin Client applications, such as secure web sites, and Rich Client applications can both make great use of this architecture for custom security behavior.

Current trends are leading to a growing need for tools for rapidly creating secure, bullet-proof, software and procedures. Rich Client applications are especially well suited to addressing these trends, which include:

• the increasing importance of remote communication and decentralized decision making;
   

• the move to deliver online financial and shopping services to the public;
   

• the increasing interdependence of Internet and internal business systems;
   

• the realization that information sharing between government and commercial organizations is vital to effective counterterrorism and disaster recovery.

Highly Secure Data Sharing

Base One's Database Library includes large-scale data sharing capabilities. The underlying architectural model is of a multi-organization network of independently owned data warehouses. Each is supported by a "Virtual Supercomputer", that is, an IBM, Microsoft, Oracle, or Sybase database plus a collection of PCs used for distributed processing and storage. Ordinary Windows computers are turned into Batch Job Servers (for distributed processing) and Base One Internet Servers (for remote database access and distributed storage).

The Database Library's security infrastructure allows an organization to provide a single integrated authentication and authorization framework to all applications. This enhances network and data security, reduces administrative requirements, and is convenient for the user experience. At the same time, the security infrastructure makes it possible to have the highest levels of security provided by controls that allow multiple, independent individuals within an organization to do administration and monitoring. Just as it is necessary for two different officers to turn their keys at the same time to launch a nuclear missile, highly secure systems must operate with multiple, independent administrative groups made up of individuals with overlapping responsibilities. This is an absolute requirement for the most secure systems used for national defense and financial transactions, for example.

Base One's architecture addresses these challenges, handling major aspects of database, application and link security for its users:

• Access privileges can be set on a per-application basis for groups of users.
    

• Each user can access all applications for which he has privileges through a single sign-on.  
   

• Secure encryption can be implemented between clients and servers.

Rich Client application security works with and enhances the access controls that come with the database and the operating system (for network and file access). Administrators can choose to do all database security through the database system's standard tools. However, administrators can also elect, for example, to use the Command Processor to do explicit GRANTs and REVOKEs in scripts. This is handy because the command files (scripts) support macro expansion, nested files, C/C++ style comments, and trap all errors with meaningful messages.

Administration and Security Concepts

Security Group records (type SecGrp) control access to a particular set of screen objects, such as dialogs, forms, menus, and individual functions.  For example a "Guest" security group can be created that only allows a limited selection of non-administrative functions.

User Group records (type UsrGrp) provide an additional measure of flexibility in choosing whether and how to implement access restrictions. For example, User Groups can be used to filter data so that members of a particular group can only access a particular subset of the database. Thus, the "Trainee Access" User Group might be restricted exclusively to operations against a test site.

The Administrative library also includes an interactive, system administration facility for controlling database access.  This allows administrators to force users to log off, restrict logons, and broadcasting warnings and other messages, for example, in preparation for system maintenance or shutdown.  BFC automatically tracks who is logged on, with what application, and assists in preventing multiple logons to the database by the same user.

User Administration

It's simple to build systems that permit managers to control the items a particular user can select, the buttons or links that can be pushed, and the screens or web pages that can be seen. Rich Client Architecture's Security System even makes it practical to efficiently control application-specific behavior such as filtering data depending on who is looking at it. This is in addition to supporting the normal database administrator authority to decide what record types (tables) a user can modify or query.

The Security System works in conjunction with the database system's support for checking/changing passwords, grouping users and granting/revoking database privileges. Programmers can easily add administrative controls for determining who should be allowed to view sensitive data or perform restricted operations.

The User Administration facilities make it simple for administrators to assign security privileges and set security rules. The System Administration facility is for controlling database access, allowing administrators to force users to log off, restrict logon to certain types of users, and broadcast warning and information messages, for example, in preparation for system maintenance or shutdown.

Database Session Control

Applications can track users without cookies and recognize them regardless of what machine they're using. The Security System's Database Session facility lets applications detect and prevent multiple logons for the same user. Besides preventing multiple logons to the database with the same User ID, the Database Session facility lets administrators see who is logged on, with what application, and that application's version number.

Web programmers will find useful services from the Base/1 Internet Server (BIS). The Internet Server has a COM interface that Thin Client applications (web sites) can use to prevent both multiple logons by the same user and attempts to circumvent logon.

BIS can be placed on the same machine with web servers such as Microsoft Internet Information Server (IIS), Crystal Web Report Server, ColdFusion Application Server, etc., to deliver security services. Web server programs call BIS functions to block requests by unauthorized sessions, prevent multiple logons by the same User ID, and to force off specific users regardless of the server they are coming through.

Web application programmers code their own data access and use BIS functions called by web server programs to register user sessions, check requests are coming from valid user sessions and force off specific user sessions. Applications using ASP.Net, ASP, ColdFusion, Crystal Web Report Server, etc., can employ the Database Session facilities of the Internet Server and Rich Client Architecture to improve web site security without compromising performance.

Encryption of Internet Traffic

The Base/1 Internet Server (BIS) and any Rich Client application can transmit and exchange messages securely over the Internet. Programmers can easily add encryption between the application and the Internet Server by linking in custom encryption and decryption call-back functions. Once this information has been linked into the Rich Client application and the Internet Server, the encryption/decryption functions are automatically called for every Internet message packet sent or received.

Instead of passing pages of HTML (a verbose, standardized, easily decipherable form of information) across the Internet, a Rich Client application exchanges only compact packets of raw data with the Internet Server. Any application can be easily adapted to use its own proprietary method of encoding Internet transmissions, with no dependence on "Secure Sockets" or any other publicly known standards. Applications have the advantage of being able to incorporate high efficiency security routines whose specifications are totally unknown to outsiders.

There are two sample encryption/decryption routines supplied. The first example is in source code form and shows a simple encryption/decryption algorithm. The second example, uses a commercial DLL to compress and uncompress the Internet messages (which also serves as a mode of encryption/decryption). This DLL comes without source code and illustrates how an isolated group of programmers might hand over high security encryption/decryption routines without compromising security. Since the source code is not exposed, the algorithms used for encryption/decryption is not revealed to the general application programmers.

Data Dictionary for Security System

Database-centric architecture speeds up security programming through the use of predefined records that contain the most basic information needed to implement most business systems. These built-in record types (tables) can be automatically added when a database is created or at a later time. The Data Dictionary is initially loaded with a dozen or so built-in record types related to user administration and security, such as User Master, Security Group, Security Rule, and User Group.

All the different built-in record types related to security are part of the Security Region in the Data Dictionary. (The Security Region, in turn, is a subregion of the System Region, which includes the basic set of built-in record types.) The Security Region's record types (tables) are grouped into the following subregions:

• User Administration
  (User Master, User Info, Security Group, Security Rule & User Group)
   

• Database Access Control
   

• Internet Server Records
   

• Database Session
   

• Screen Region (forms, menus, links, web pages, tabs, buttons, etc.)
  (Screen Action, Screen Object Type, Screen Dictionary)

• Lists all the users who have access.
• Each user is assigned to a security group and a user group.
• Every user can have a text note attachment (e.g. for phone #, email address or any other useful information).

User Administration

Base One's architecture offers major extensions to the more limited security facilities provided by the DBMS. Programmers and operations staff can make immediate use of the pre-built Rich Client security system whether they are building Thin Client (web) applications or Rich Client applications to support the web site.

The security design is built on the standard user and group access controls provided by Microsoft, Oracle, IBM and Sybase database systems. Rich Client applications get most of the security features automatically, while programmers can easily incorporate any of the security features, as needed, into Thin Client applications.

The User Administration facility simplifies assigning security privileges and setting security rules. Every user belongs to a User Group and a Security Group, which has a set of associated Security Rules. So Base One provides two separate methods of grouping and controlling users (which can be tied into the single method of grouping users provided by the database system).

User Groups might be, for example, "ABC Company", "XYZ Company, London Branch" and "Trainee Access". The User Group might be used to filter the data displayed, so that the different groups only handled their own data. Most frequently, User Groups are used to control Data access, i.e. to different logical portions of the database.

Security Groups might be, for example, "Administrator Privilege", "Guest Privilege", and "Customer Privilege". Each Security Group is associated with a set of Security Rules, which determines what the user can view and what actions can be taken. It's easy for administrators to use the Foundation Application to add Security Rules that can determine, for example, whether or not the users in that Security Group can view particular screens or web pages, or press particular buttons, menu items or links. Most frequently, Security Groups and Rules are used to control Screen access, i.e. what visible facilities of the application are available to the user.

The Data Dictionary has a Security Region, which has the security records. Within the Security Region is the User Administration subregion that contains the User Master, Security Group, Security Rule and User Group built-in record types (tables).

Every user has a User Master record that includes a User ID (Logon ID), User Code (User Number), and that user's Security Group Code and User Group Code. In addition, the User Master record contains a User Type Code. 

In Rich Client Architecture, there are six types of users: Full Users, Full Batch Users, Lite Users, Lite Batch Users, Super Users, and the Database Setup User. Full Users have actual database logon IDs. Lite Users do not and require a Super User to do data access. Batch Users are used for distributed computing. The Database Setup User provides a means of creating or accessing a database when there are no User Master records present.

User Master Screen

Full Users

A Full User is a regular database user. The user has a User ID and password that initially were assigned through the administrative facilities provided by the database vendor.

Full Users have the advantage of being able to be managed through the database system's access controls (i.e. SQL GRANT and REVOKE for table privileges). In high security systems, there is the additional advantage that separate application and database controls can be maintained by two different sets of administrators. A user's database activity can be tracked with both custom application logging and standard database vendor tools. Full users are most often used in client/server business systems.

However, for most commercial web sites and some client/server applications, Full Users are not appropriate or efficient. To avoid the need for Database Administrator participation for each new user and to avoid transmitting real database logon IDs and password, use Lite Users instead of Full Users.

Lite Users

Lite Users are especially efficient for large scale applications. A Lite User is not known to the backend database system. A Lite User ID is not a real database logon ID requiring a real database password or registration by a Database Administrator. Therefore, a Lite User ID and password can be assigned programmatically.

Lite Users can be used for both low security and high security applications. Since Lite Users are not themselves authorized database users, the Lite User can not be used to circumvent application-level security (by unauthorized direct access with standard commercial database tools - a dangerous security hole). This is especially important for programming web sites because of the ease of security violation techniques, such as packet sniffing, to find User IDs and Passwords on the Internet.

Lite Users share real database logons (Super Users), which makes efficient connection pooling possible. Database systems slow down substantially as the number of logged on real users increases. By managing Lite User data requests through a small number of Super Users, the database system can support far more simultaneous users.

To create a new Lite User, all that is needed is a new User Master record. Adding, changing, and deleting Lite User can be done through the same user administration facilities used to maintain Full Users.

Full User Vs. Lite User

• Lite users do not need a real Database Logon ID. Behind the scenes, the Internet Server uses a SuperUser ID to connect to the database. This is to avoid passing a valid database Logon ID over the Internet.
   
• Both Full & Lite users can access the Rich Client app in 2-tier mode or 3-tier mode.
   
• Batch machines (for distributed processing) can be either Full or Lite "Batch Users".

Like Full Users, Lite Users can be added through the standard User Administration facility of a Rich Client application. User Master records can also be added through the Command Processor, using LoadRecs or INSERT SQL. User Master records can be added programmatically through the Database Library AddRec() and AddSet() functions. Finally, User Master records can be added by web applications using any of the proprietary database interfaces supported by their application server.

Lite Users are assigned to User Groups and Security Groups (with their associated Security Rules) in their User Master records, just as is done for Full Users. Every user is given a unique number (User Code). The Lite User's Code (and not the Super User's Code) is used to create the audit information in the Last Modification Keys generated when records are added or changed in Rich Client Architecture. So, it's possible to figure out which user did what, whether the user is a Full User or a Lite User.

Lite Users obey the backend database restrictions (GRANT & REVOKE) of the Super User through which they are connected. Similarly, the backend database logging of activity for Lite Users is tracked by Super User ID, whereas custom application logging can use the more specific Lite User ID.

The Base One Internet Server makes it easy for Thin Client (web) applications to use Rich Client Architecture and Lite Users. The Internet Server can simultaneously support Rich Client applications directly when they are operating on the database from across the Internet.

Super Users

Super Users are needed to do the database work for Lite Users. Lite Users are always connected to the database through a Super User. A Super User is an actual database logon ID, like a Full User or Database Setup User, and has the additional capability of supporting one or more Lite Users. This model is especially useful for large scale Internet applications.

Lite Users obey the backend database restrictions (GRANT & REVOKE) of the Super User through which they are connected. Similarly, the backend database logging of activity for Lite Users is tracked by Super User ID, whereas custom application logging can use the more specific Lite User ID. If you assign a separate Super User for each Internet Server, you can track database activity back to a particular application server.

The Super User's password (a real database password) NEVER needs to be passed across the Internet for a Lite User to logon. Thin Client applications (web sites) built on Rich Client architecture also do database access through the Super User supplied to the Internet Server. For simplicity, performance and security, all browser users can be Lite Users. The Super User ID is the actual database logon used by the web application server for all database access. Having a small number of Super Users (one or less than one per server) makes high efficiency database connection pooling (sharing) possible.

For web sites and 3-tier Rich Client applications, Super User IDs and Passwords can be restricted to physically secure environments. This reduces the vulnerability of the database to direct hacking. The Super User ID and Password is not stored visibly in the database and can be kept confidential. So operators and users enter their own Lite User IDs and Passwords and the Super User info can be handled by secure servers.

Super Users can be assigned to a Security Group and User Group with no access, which effectively stops Super Users from using an application directly. The Database Manager class has all the Database Library functions related to logging on, including: SetLogonUsr(), which can accept the ID and password for a Full User or a Lite User and SetSuperUsr(), which only accepts the ID and password for a Super User. 

Batch Users

Batch Users are used for distributed computing. When you log on to a Rich Client application using a Batch User ID, the computer becomes a Batch Machine. Any local or remote machine can become a Batch Machine if it logs on to the system using Batch User ID. Batch machines are especially useful for doing long-running, coordinated, database jobs. (Batch user IDs should be used only by Rich Client applications and should not be used with Thin Client applications.)

There are two types of Batch Users, Full Batch Users and Lite Batch Users. Full Batch Users are like Full Users and have a real database logon user ID and password. Lite Batch Users are like Lite Users and do not have a real database logon user ID. Instead, they must use the Super User ID to connect to the database. This is the only difference between Batch Full Users and Batch Lite Users. Otherwise everything else is same and both turn a computer into a Batch Machine and start the batch processing.

Batch jobs can be submitted and tracked across the Internet by any Rich Client application, but, for greatest efficiency, the Batch Machines themselves usually should be on a LAN with the database attached. For example, you can have the Internet Server and the Batch Machine running on the same computer as the database server (and web server, as well). You can then logon to a Rich Client application across the Internet, using a Lite User ID, for example, and submit jobs and monitor the results from a remote location - while getting the performance benefits of the running jobs locally.

User Master Records

User Master records contain basic info about all authorized users of the database, including the distinction between "regular" users and batch users. There is one UsrMast record for each user. Each user is assigned to a security group and a user group, and there are provisions for specifying a per-user log file as well.

User Sort Name

• You can automatically generate a unique Sort Name by supplying the user's full name.
   
• Only the Sort Name must be unique. So, for example, if there are two "Mary Jones", they can have the same Full Name, but a policy for uniquely modifying the Sort Name should be established.

Database Session Records

Database Session records track who is logged on, with what application, and assists in preventing multiple logons to the database by the same user. There is one Database Session record per logged on user.

The Database Session List form view lists all the users and applications logged on to the current database. Each entry includes a User ID, User Name, Logon Date Time, Application Name (i.e. what .EXE), and Application Version (e.g. '2.1'). All types of users are listed, including: Full, Lite, Batch, DbSetupUsr, and Super users. Often, Thin Client applications do not know when a user is finished and depend on time-out to end sessions. (This is a consequence of the "stateless" behavior of Thin Client connections to users.)

Database Session Support by the Internet Server Manager

The Database Session functions of the Internet Server can be used by Thin Client (web) applications to prevent both multiple logons by the same user and attempts to circumvent logon. These security calls can be made from ASP.NET, ASP, and ColdFusion programs using Microsoft's COM and .NET interface.

Rich Web Site that can Force Off Duplicate User

• Thin client application that uses Rich Client Architecture, and therefore can detect an attempt to logon more than once with the same User ID.
   
• Only one logon per session is allowed - multiple users can not access the web site with same User ID.
   
• If a user logs on to the web site with a User ID that is already in use by some other user, then the application forces off the other user from the site, and the other user gets the force-off message.