Adlib offers application user login functionality, and a comprehensive access rights mechanism to define precisely which users have what rights when they're working with Adlib. This functionality extends the standard Windows single sign-on authentication, which of course should always be the first line of defence.

User authentication through application user login

From Adlib 6.0 you have the possibility to set up an application-bound login procedure. Then, when starting each (instance of an) application for which this has been set, first a login window appears in which the user must enter his or her user name, password and possibly an (Active Directory) domain. No access will be granted to the application until the user fills in the correct information.

You, or your system administrator, has to set up this way of authentication explicitly. As long as that has not been done, Adlib will use the user credentials from the Windows login for applying any security policy.
Make this setting on the Application authentication tab of the properties of an application structure file (.pbk) that you have opened in the Application browser in Designer. So, per application you can set this user authentication.
First choose one of four possible methods for saving the user names and passwords:

Save the edited pbk file after you have set an authentication method, and (close and) start the concerning application to test your settings.
Note that, whatever way you choose to have users log in, the name with which the user logs in will be used to assign access rights through the roles mechanism (if that is used in your application). So make sure that any user names linked to roles, match the user names as registered in the authentication model that you chose.

The Adlib access rights mechanism

In the Adlib access rights mechanism screen files, objects in a database definition (namely databases, datasets and fields), and objects in an application definition (namely the application, data sources, methods, export jobs, output jobs and friendly databases), can all be protected. (Methods are access points and software functionality like searching in different ways, creating new records, deleting records, using pointer files, global updating, importing, exporting, and deriving.)

In Axiell Designer this can be set up in the following ways, that may be combined:

The user credentials required for this mechanism to work, are obtained from the Windows user authentication if no Adlib application user authentication has been applied, otherwise the latter provides the necessary credentials.

Use the roles functionality

In an application definition you can include a list of all users of the application. In the properties of each user you then assign a so-called role to which the user belongs (such as staff, user, public, etc.). Then you may include any role on the Access rights properties tab of an Adlib file or object (as listed in the introduction above) and assign access rights to the role. Access rights that are applied this way, apply not only to the file or object itself but also to all sub-objects in it, which saves you work. And access rights that you apply to roles for objects in an application definition can only be further restricting than any access rights applied to the same roles for objects in a database definition; they can never be extended.
One special role is $REST. This role should never be assigned to users explicitly. Its purpose is to be able to specify access rights to the current object for all users who's role has not been assigned access rights to this object and for all users without a role. So if you've defined users and roles in the pbk, but for an object you do not assign access rights to these roles, while you do specify that $REST should get e.g. read access, then all users will have only read access. However, by default $REST has not been set anywhere, and if you do not assign access rights to any roles, then all users will have full access.
A second special role is &ADMIN (available from Adlib 6.6.0). This role should be assigned to administrator users, but access rights must never be applied explicitly to this role because users who get the $ADMIN role have full access rights by default, plus the right to unlock manually locked fields and even the right to change the name of the record owner and user access rights per record if record authorisation is active for the database. The $ADMIN role and its inherent rights also have priority over access rights assigned to $REST.The $ADMIN role and its rights even overrule access rights for application roles. The latter means that users with the $ADMIN role may get to see an Adlib application in quite a different way, namely with all possible details screens, methods, access points and all possible data sources: this is because in model application 4.2 and higher, application roles are the filter that determines if an object appears in a certain application or not. Since that filter is ignored for an $ADMIN user, he or she gets to see all application objects.

Note that on opening of the Application browser, it only loads Adlib objects from the currently set root folder in memory; any objects in a subfolder will only be loaded too, if you open that folder. The advantage of this is that the start-up time of the Application browser is being reduced. Other than that, it is only relevant for your work when you are editing access rights for application or database objects: in the Roles drop-down lists that you encounter on those properties tabs you'll find all harvested roles from all currently loaded Adlib objects (so you won't have to remember them or look them up all the time). But to allow Designer to harvest all roles from database and application objects, you must have opened the data and application folder(s) nodes at least once in this session, and they will remain in memory when you close those nodes again.

Access rights and roles, for methods - If you are about to apply access rights to roles for methods, you'll find there are many combinations of method type and access rights of which the consequences may not be immediately clear. Therefore, the following table provides an overview of all possible combinations and their consequences.
For instance, if you set a method of the Delete records type (because you want at least some users to be able to remove records from the current data source), and you have specified a number of users that fall into two roles, staff or public, you may assign the public role any of the access rights None, Read or Write because they have the same effect that records cannot be deleted. Because staff must have Full access rights for this method, you don't need to assign these: Full access rights are applied to any role for a method by default (unless the application's default access rights have been restricted), if a role's access rights have not been set for this method.
Everything in the table in light green is staying on the safe side, disabling functionality or different types or searching; everything in cyan means enabling some or all functionality of that method.

The application Identification role - A different type of role is the application Identification property. You do not assign users to this role, because this role automatically applies to everyone using that application! With this role, a standard screen for instance, may be read-only in one application, whilst it may be editable in another application.

More details - See the Help topics for the Access rights tab in the properties of a specific Adlib object, for detailed information about access rights for that particular object.

Generating an overview of applied access rights

From Designer 7.4, the Create rights documentation option is available at folder level in the Application browser's tree view. It harvests all roles/rights information for all files in the selected folder, that have actually been assigned access rights for some object. So users and their roles won't be listed here and roles (both application roles and user roles) will only show up in the documentation if they have been used to apply access rights to a data source, a method or other Adlib object in that folder. Right-click an Adlib folder (data, xplus, library or museum for example) and choose Create rights documentation in the pop-up menu.

The resulting documentation lists only objects for which access rights have been specified explicitly and sorts these per role.

Like other documentation created by Designer, you can save and/or print the generated file.

Adjust the standard security for an application

In the Default access rights property of an application definition, you may set the standard access rights for this application, that must apply if no access rights have been set for an object through the roles functionality. If a role and access rights have been mapped for any application object or database object, then those access rights always have priority over the Default access rights for the application (whether those role-specific access rights allow more or fewer user actions than this default).

Use the authorisation functionality

With this method of security you can set access rights per record per user or role. In each record you then list users and/or roles* that have different access rights from the norm. This is useful if some records in a database may only be accessed by some employees because of sensitive contents for example, while other records may be accessed freely.
There are two different ways of implementing this functionality:

* You can only use a user name in this functionality if no role has been assigned to that user in the application definition (whether that role is actually used anywhere else or not). This is because when Adlib searches for access rights to apply, it searches by means of the role assigned to a user. So if a user James has the role Management and you apply the authorisation functionality discussed here, you will have to enter the Management role in records instead of user name James. Of course, then the record access rights apply to all users with the Management role, not just to James. Users without roles however, can indeed be entered in records; you can mix user names and roles here.

All applicable database settings can be found in the Authorisation and security box on the Database properties tab for a selected database in the Application browser. So you decide per database which authorisation method you want to use (or none at all of course).

- Implementing general authorisation through Exclude or Include

- Implementing specific authorisation through Rights

In the running application, only the owner of a record (a single user or all users with a certain role) can fill in or change the three new fields. All other users can never adjust the contents of these three fields (unless there is no owner at all). If they have access to the record, then at the most they can read these fields, even if they have full access.

Each time that a user now tries to open and/or edit a record in this database, Adlib will check if that user has the appropriate access rights.

Use Active Directory groups in defining roles

The Active Directory (or Windows NT) group to which a user belongs, can be used to specify the access rights for an Adlib object. This way you only need to register the individual users in the appropriate Active Directory groups and then register those Active Directory groups in the Adlib application definition. Simply include the group name in the Users list of the relevant Adlib application definition and assign it an appropriate Adlib role. For use within an adlwin.exe application only, you can name such a role anyway you like, but for wwwopac.ashx (the Adlib API) to be able to apply access rights to such users, the role name must be identical to the Active Directory group/Adlib user name because the API has no access to the application definition containing the Adlib user-to-role mapping and can only use the Active Directory group name of the logged-in user as a possible Adlib role (access rights in Adlib are always assigned to roles). So we recommend that when you include an Active Directory group name as an Adlib user in the Adlib application definition, you assign it an Adlib role with exactly the same name.
The Adlib security system will then not only check the Adlib access rights of the Adlib role for the specific Active Directory group (specified as Adlib user), but also the Windows access rights for the Active Directory group under which the current Windows user falls. The most limited access rights of the two will be used if more than one restriction is used.
For example, the Active Directory group students may have Write access (on Windows/SQL level) to a specific Adlib SQL database, but "John", who is a member of that group may have only Read access for a specific field in Adlib. In this case (for safety reasons) the Read access has priority as far as the relevant field is concerned. In this example, an Adlib user named students with the role students has been specified in the Adlib application definition and the relevant data dictionary field has been assigned Read access rights for the role students.
If a user is linked to several NT or Active Directory groups, the individual rights are assigned to the group in which the user has the most rights. Individual rights always take precedence over group rights.

Temporary Adlib tags that are not specified in the data dictionary always have full rights, independent of surrounding rights. This prevents side-effects in such temporary fields, caused when Read access rights are assigned to the databases, on Windows level or from Adlib. If said temporary field has no write authorization, no value can be assigned to it by the software itself: a value must be written to a database, even though it is temporary.