This is an advanced subject. It is only applicable to the Enterprise version of Alventis. And it's just plain scary. So don't tell us we didn't warn you.

 

Alventis Multi-User Security Model

 

Alventis supports a rather sophisticated multi-user security model. The entire user/security system works on a per-server basis, so we'll assume that we're talking about a single server in the following discussion.

 

The users exist in a hierarchy. There exists a single "Root" user who should not be used by anybody (i.e., no copy of Alventis should be configured to access the server with Root credentials) for reasons that will become apparent shortly.

 

Every user is (or at least can be) a Manager. That means that other users can be his direct subordinates. Such direct subordinates of a user/manager form his Group.

It follows that each of these subordinates being just a user at the same time can also be a manager for more subordinates (his group), and so on.

This constitutes the hierarchical tree of users.

Direct subordinates of Root are said to be at the Level 1 of the tree. Their subordinates are at Level 2, and so on. You can have up to 50 levels, which should be enough for just about any enterprise.

 

Alventis' security revolves around Rights given to user Groups with regards to Objects. It's actually simpler than it sounds. Instead of giving you simplistic examples, we'll start by telling you what Objects we have in mind. They are:

Table
Form
Select Query
Non-Select Query
Report
Creation

The latter is not a real Object of course, but it's convenient to think of it as if it were one.

 

 

User Groups we have already discussed. These are all users who are direct subordinate from one particular Manager user. It therefore makes sense to refer to that Group of users by simply referring to its Manager. Which means that in a sense at least as far as Rights are concerned (which is all we care about) a Group is essentially equivalent to its Manager. Not in the sense that the 3 users Bob, Tom, and Jim who report to their boss James are equivalent to him, no. It is in the sense that Bob does not have any Rights to any Objects on his own. Bob's access privileges are based on his Group's Rights, which simply mean: the Rights of James.

 

It's important to get this straight, so we'll try to say it differently. If we ever wanted to know what access privileges Tom has, we would not go looking for any Rights "attached" to his Username (those would be the rights of his Group of subordinates, but not of him). We would go "one level up" and see what Rights his Manager James has because those would be the rights of James's group which includes Tom, and hence apply to him.

 

Each Right grants some access privileges (a few related ones). There is no mechanism per se in Alventis to deny an access privilege. Each Right applies on the one hand to a user (read: group/manager), and on the other to an Object. (You can think of the Right as the central "bridging" element in a many-to-many relationship between users and Objects if it helps and if you understand what it means).

 

 

Right Hierarchy.

 

Rights too have a hierarchy of their own. On the Object "side", a Right can apply to basically one of two things:

An explicitly specified Object, e.g., Table Contacts of Database such-and-such.
A class of Objects, e.g., Tables. This is typically expressed as "Default Table" and essentially means "all tables, unless there's a more specific Right to the table of interest".

 

On the user "side", there's even more choice:

A particular Group of a particular user. Everything is specified explicitly, no deviations.
A Level. A Right can be specified as applicable to all users who belong to a particular Level of the user tree (see above).
Default. This simply means "everybody".

 

The overall principle behind all this is quite simple. Imagine a huge collection of various Rights. Some apply to Groups, some to Levels. Some apply to individual Objects, others to Object classes. Whenever Alventis must figure out if a specific user (the one currently logged into a specific Server from that specific copy of Alventis) has particular access privileges to a specific Object, it simply goes through the Rights collection in the following order:

is there a Right for the specific Object and this user's Group

is there a Right for the specific Object and this user's Level

is there a Right for the specific Object and "Default" user

followed by:

is there a Right for the Object class and this user's Group

is there a Right for the Object class and this user's Level

is there a Right for the Object class and "Default" user

 

As soon as Alventis finds a match (going top-to-bottom), it returns whatever access privileges that Right specifies. And yes, it just might be that somewhere down that list there does exist a Right granting even broader privileges, but Alventis won't take it into account. Incidentally, this can be seen as a way of "denying" someone some access privileges: Default user (i.e., everybody) may have full Rights to, say, a Table, but we could "give" one restricted user his own "personal" Right that does not grant any privileges to that same table. The more "specific" Right will be found first by Alventis and that's what will be applied to this user.

 

 

Rights of Author.

 

And you thought it couldn't get any more complicated than that? Hang on.

Every Object in Alventis has an Author. This is just the user who created that Object, nothing fancy. But as we have discovered, Alventis users are arranged in a hierarchical tree. Wouldn't it be nice if this could be put to some twisted use? For example, make it so that a user could only access records created by members of his Group. Or a manager could access records of his subordinates but not his own manager. And so on. This is exactly the kind of flexibility that this feature offers you. Here's how it works.

 

Every Right has 3 Hierarchical Access Level specifiers: Read, Edit, Delete. Let's take Read, for example. The possible values are quite numerous, but they simply go in order restrictive-broader-broader-broader-... like so:

 

Self means whatever access this Right is granting, it is only granted to Objects (say, records) whose Author is the user himself or any subordinate of his, even an indirect one. So, basically, he can read his own records plus those belonging to anybody "under" him in the tree/pyramid.

 

Group means he is granted access to all records belonging to (i.e., created by a user of) this user's group plus all their subordinates. A little better.

 

Manager means he gains access to records authored by his manager plus all of his manager's subordinates. Generally speaking, whenever a user gains access to records of user X, he is automatically granted same access to records of all X's subordinates. So we won't repeat it each and every time.

 

Manager's Group access to records of his manager's entire group.

 

Mgr's Manager higher up, we get to his manager's manager.

 

Mgr's Mgr Group higher yet, the group of his manager's manager.

 

And so on for all Levels ad nauseum. Essentially, the "movement" upwards in the user tree always works in steps: up to a manager; include his group; up to his manager; include his group, etc.

 

Hierarchical Access Levels make sense for some but not all types of Objects. They can be used for Tables, Queries of both kinds, and Reports. They are not appropriate (and are hence unavailable) for Forms (i.e., InfoViews) and Creation.

Use of Rights of Author / Hierarchical Access Levels may slow things down a bit in Alventis, but it's up to you to gage the performance drop. We do not expect it to be significant.

 

If you decide to steer clear from this feature because you might not need this much flexibility (or because we finally managed to confuse you out of your wits), you can effectively disable it by simply setting all (or some) Access Levels to a level which is higher than the height of your entire user tree. For instance, if your mighty user tree had 5 levels, it would be sufficient to set the Access Levels to "Mgr 6 up" which "overshoots" the Root of the tree and makes this whole feature irrelevant and thus disabled. To avoid counting levels at the risk of running out of fingers, you can simply set it to "Mgr 49 up" and forget it.

 

Before we get into all the nitty-gritty stuff, let's examine a scenario where Alventis Security could be used as a feature.

 

Human Resources. A company could have an Employees table that would record everything known about them. The HR department would want to have full access to all fields from the table. They could have an InfoView that implements all available fields and Queries/Reports to match. Managers may have a need to access just their subordinate's personal records, and perhaps not all the available fields. A different InfoView accessible to just them + appropriately set Hierarchical Access Levels could do the trick. Employees themselves may benefit from being able to access all records, but only the first/last name, telephone/extension, and e-mail fields. Yet another InfoView with just these fields would suit their needs. Since rights can be set not only on a per-table, but also on per-InfoView basis, it is possible to expose different sets of fields of the very same table to different groups of users.

 

This concludes the overview of Security in Alventis. Time to take a look at how all this is maintained and administered.