This is an advanced subject only applicable to the Enterprise version of Alventis.

We are assuming that you have read the previous Security Overview chapter.

The Administration form is accessible from the Database Explorer form: highlight the Server you want to administer and click the Administration button. Note that everything that pertains to multi-user security in Alventis also applies to the Local Server – even if it is infinitely more useful for Remote Servers.

Now that Alventis' security model is intimately familiar to you, most of the Administration form itself should become quite obvious. The form uses a tabbed interface and has several buttons at the very bottom. The buttons pertain to some specific tab sheets, but have been placed here simply to remind you that their respective items may need saving (they will become enabled when this happens). Let's go over the tab sheets one-by-one.

Users

The Users and Groups tab sheet has a single grid of users. Each user is a manager of his Group, remember? That's why there are no Groups per se listed anywhere. The only thing that pertains to user grouping here is the arrangement of the users in a tree structure by means of establishing the manager of every user. Except for Root who is at the very top of the tree and thus doesn't have a manager.

Let's do a quick run through the columns.

UID is the unique User ID. It is auto-assigned when a user record is created.

Created/Modified are the usual auto-set dates.

UName is the unique Username that you create to identify users. It will appear in InfoView and other forms when appropriate.

Password is the user's password. Passwords are case-sensitive and can include whatever characters you like. They can be up to 36 characters in length. All passwords are hidden behind asterisks to protect them from prying eyes. You can reveal and edit them by simply activating the corresponding cell, i.e., "entering" into it by hitting Enter or clicking the already-focused cell with the mouse. Can be useful when users inevitably forget their passwords.

P/w Created. Reserved for future use.

Admin specifies if a user has the ultimate privilege of administering this Server. There would normally be only a single user with this privilege, and this is preferred to keep security as tight as possible. But you may grant this privilege to more than one user if you wish. There's only one caveat: if more than one Admin users attempt to administer the same Server concurrently (and in particular, change the same "area": users, Rights, etc.), Alventis is likely to get confused. That is, the Admin who saves the configuration last is likely to overwrite the changes of the preceding Admin. So it is your responsibility to prevent this from happening. The easiest way is of course to have a single Admin. Otherwise, make sure they don't "step on each other's toes".

Group is the single column that establishes the tree hierarchy. It is here that you specify which manager's subordinate this user is. Just pick the right manager from the combo box. If an existing user does not appear in the list, check (in more senses than one) the next column.

IsMgr is there to help you manage the user hierarchy. If you know that a particular user is not intended to become anybody's manager and have subordinate users, you can uncheck the IsMgr checkbox for him. All this does is remove his Username from the Group combo box's list, so it doesn't needlessly clutter it. If a user is already somebody's manager, the checkbox is grayed-out and you can't change it. If the user is currently nobody's manager, you can freely check/uncheck it.

FName/LName/Tel/Email/Comment. These are all for your information only. They are not used anywhere but here, so fill them out any way you find useful.

Once you modify anything in the user hierarchy, the Save Users button becomes enabled. You don't have to click it right away though: perhaps you want to adjust the user's Rights first to keep your security "in check". Just don't forget to save your changes at some point before closing the form, because Alventis will not prompt you to save your changes.

And that's all there is to maintaining users. Let's do something about their Rights now.

Rights

Sorting out who's got what Rights to what can get complicated. Which is why Alventis offers you not one but two approaches implemented in two separate tab sheets: Rights by Group and Rights by Object. Both contain the same exact information. It is only the way that information is presented to you that is different. Which one you prefer may depend on your personal taste or, more likely, the task at hand. You can freely switch between the two tab sheets as much as you like. In either case, Rights are listed on a per-Database basis. You can switch between the Server's Databases using the combo box at the top of either tab sheet. Doing so requires you to either save or abandon your changes (if any) to the currently-edited Database.

Rights by Group lists all Rights in a single "flat" grid. You can group the list by the Group/Level column to see what Rights each Group or Level has. This is what gives this tab sheet its name and makes it reminiscent of a Capability List that you may be familiar with. Let's go over the available columns.

RightID is as usual the unique auto-incrementing numeric ID auto-assigned to each Right when it is created.

Object Class is the Object Class: Table, Form, Select Query, Non-Select Query, Report, or Creation.

Object displays the Object this Right applies to. As we have learned earlier, it can be, e.g., a specific explicitly-specified table such as Contacts or "Default Table". Same goes for most other Object Classes.

Group/Level indicates who this Right applies to. This can be "Default", a particular Level, or a particular Group.

Level-Read/Level-Edit/Level-Delete are the Hierarchical Access Levels for this Right.

Privileges is a column that displays the list of access privileges this Right grants.

Only the 3 Hierarchical Access Level columns allow direct editing right in the grid. The rest of them are read-only. To edit the Right, you double-click it in the grid. This will open the individual Right in a dialog box. The appearance of the dialog box depends on the Object Class whose Right you are opening. While the specific contents of the dialog may vary slightly, the basic principle is always the same, so we'll only illustrate it on the example of a Table Right dialog.

All the checkboxes represent individual access privileges. Those that are grouped together with a Slider control have a certain degree of inter-dependency: enabling a certain privilege automatically enables "lesser" privileges and vice versa. Higher privileges are higher on the Slider scale, so it should be quite intuitive. You can use either the Slider or the checkboxes (or both).

The Hierarchical Access Level group will be present for Rights to which it applies, and there should be nothing enigmatic about it by now.

We'll discuss the specific access privileges of each Object Class shortly.

Rights by Object lists the very same Rights, but in a hierarchical grid or set of grids grouped by Object Class. As such, they can be seen as similar to an Access Control List you may have encountered elsewhere.

The first several columns are identical to those of the Rights by Group grid described above, so we won't repeat ourselves.

The remaining checkbox columns represent individual access privileges. As simple as that.

In this combined grid, you can edit Rights directly by altering values of the corresponding cells. You can still open each Right in its own dialog if you prefer – again, by double-clicking a Right in the grid.

Whichever Rights grid you use, you can create a new Right as if you were creating a new record in the grid – by hitting the Insert key. You are prompted for what the new Right should apply to and who it should apply to, i.e., the Object and the Group/Level respectively. The prompt automatically ensures that you do not create duplicate Rights, i.e., two Right records that apply to the same pair of what/who. Once a Right "connecting" an Object and a Group/Level has been created, you cannot modify this connection information. You can only edit the Right's access privileges and Hierarchical Access Levels, if applicable. You can of course simply "replace" a Right by deleting the old one and creating a new one. You can delete a Right from either grid as you would delete any grid record: highlight the Right and hit Delete or Ctrl-Delete on the keyboard.

Whenever you create a new Database, Alventis initializes Rights to a "maximum access" default set that gives everybody full Privileges.

Let's quickly go over the specific Access Privileges that you can grant to Objects of specific Classes.

Tables have the largest assortment which is listed below.

General Rights pertain for the most part to privileges that affect your interaction with tables and their records in Alventis:

Delete means right to delete records in the table

Create means create new records in the table

Edit means edit existing records

Read means, well, read or view records

Design Rights are related to what you do with a table in Alventis Designer:

Delete object means delete the table itself

Delete fields means delete any of its fields

Add fields means create new fields

Edit means edit existing fields

Read means gain at least read-only access to a table

Besides the above grouped privileges, there are two more:

Export means export the table or its data from Alventis

Import into means import data into the table

Forms have a group of Design Rights that greatly resemble those of tables:

Delete object means delete the form itself

Delete fields means delete any of its fields

Add fields means create new fields

Edit means edit the form in any way

Read means being able to at least open the form in Designer

Beyond these, there's a single right relevant to forms in Alventis:

Open means opening the InfoView form in Alventis

Both Select and Non-Select Queries have the same set of privileges:

Delete object means delete the query

Edit means edit the query

Set parameters means editing the query parameters

Read means opening the query and executing it

Reports have an identical set of privileges with a virtually identical meaning:

Delete object means delete the report

Edit means edit the report

Set parameters means editing the report parameters

Read means opening and using the report to produce output

In addition to the above, Reports have two more:

Print is rather obvious

Export means exporting Report Output via the Save Output command

Creation has privileges to create new objects in either Alventis or Designer, as the case may be. We'll just list them for the sake of completeness:

Table

Form

Select Query

Non-Select Query

Report

Administrative Style and Hidden/Sticky

Once you have made any changes to Rights, the Save Users and Rights button becomes enabled. As its caption suggests, it saves Users/Groups if necessary, and their updated Rights (it is not possible to save Rights updates without saving the users first). Don't forget to press this button before exiting the form – if you do indeed want to save your changes.

The remaining tab sheets pertain to the administration of the Server but have almost nothing to do with security, except for a portion of the Settings tab sheet, so let's get it over with.

The part that interests us is on the right-hand side of the tab sheet. At the top, we have the Levels grid. This allows you to essentially name the Levels the way you want to make them more identifiable in whatever Right-related combo boxes list them. The Level column is auto-set to the level number. The Name is the level name that will appear in combo boxes. The Comment is as usual, for your "notes to self". You have to name levels in sequence, i.e., you can't have named levels 1 and 2 and suddenly decide that you would like to name level 5: you have to name levels 3 and 4 first. You can re-order existing levels by dragging them around with the mouse, even several at the same time.

The Table Protection group has just a single checkbox Table Password Protection and an Apply/Reapply button.

But before we tell you what this checkbox does, let's discuss the issue of data file security for a moment. In this case, we are no longer talking about Alventis' Security Model, Rights, Groups, and so on. All of the above can allow or prevent Alventis from accessing certain records or kinds of items. The key word in the last sentence is "Alventis". Alventis takes upon itself the responsibility of accessing objects according to its user's privileges. Any other application capable of accessing the data would not be bound by this responsibility and would therefore gain full unrestricted access. But it's not quite that simple either. Let's see what happens between a Client (Alventis in our case – but generally speaking any application that accesses the data from the Server) and a Server when they communicate.

First, the Client needs to know the Server's address to even attempt to establish a connection. In the case of the Alventis Server, this corresponds to Address and Type/Port/Service. Plus the Client needs to know the Server's Remote Encryption Password. Unlike the Address and the Port, the latter is not directly visible to Alventis users, so a security-conscious System Administrator could install Alventis for everybody in the enterprise without ever telling them what the Remote Encryption Password is. Alventis would know it but the user would not. That's not the only password at play though. Every user also has his personal password – the one he uses in the Authentication Dialog. So, an "outsider" who may have found out the Server's Remote Encryption Password still needs a valid Username and Password to make a successful connection to the Server. This means we only need to worry about a malicious user with valid credentials and the knowledge of the Remote Encryption Password. If a mean-spirited user did know both of the above passwords, he could then, in theory, connect to the Server using an application other than Alventis and gain direct access to whatever tables the Server has to offer. We are not aware of any applications that would provide such functionality, so it's a somewhat far-fetched scenario, but it is possible. We can imagine yet another one. If the Server (the application that constitutes the Alventis Server) is running on a machine that someone can gain direct access to (physically or via the network), he could obviously get to the data table files and do whatever he wants with them.

The solution to the last problem is: run the Server under properly configured Windows on a well-secured machine that users would have no physical or other unauthorized access to. The only open access channel would be the Port needed by Alventis. Even a partial discussion of this level of security is beyond the scope of this Guide, so you'll have to refer to any good book on Security. But we still haven't done anything about the possibility of someone using the proper Port access channel from software other than Alventis. Well, there's really only one thing you can do against this hypothetical threat: encrypt all data tables (and some system tables used by Alventis).

The tables are encrypted on-disk using the strong Blowfish algorithm, so the perpetrator would have to know yet another password regardless of the fashion in which he may have gained access to the Server (physical or via something other than Alventis). The good news about that Table Password is that neither the Alventis user, nor the System Administrator, nor even we know what the password is, and we'll just leave it at that. Alventis and the Server arrange it between themselves. The bad news is... well... the same: since nobody knows the password, if something were to go wrong (data corruption caused by power outage or hardware or software failure) you put yourself at a somewhat greater risk of losing access to your data. On the other hand, if you are this serious about data security, you are undoubtedly serious about data backups, right? So, if you are in a habit of performing regular rotating data backups, the risk of losing your data can hopefully be considered negligible. You should still remember that it is your full responsibility to prevent data loss by using backups, uninterruptible power supplies, reliable hardware, and a well-tuned installation of Windows. Oh, did we mention that you should do regular backups?

So, now you know. If you check the Table Password Protection checkbox and hit Apply/Reapply, the Server's tables become encrypted on the Server's disk. You can leave the checkbox checked (assuming it already was in that state) and hit Apply/Reapply again, in which case it will re-encrypt everything with a different password. To decrypt the tables, uncheck the checkbox and – guess what – hit the Apply/Reapply button.

This concludes the topic on Alventis Security Model and Implementation.