Access Keys:
Skip to content (Access Key - 0)

Activity 2.2.1 Tool 1.2 Administration

User Access

There will be two levels of User Access, Workbench Users, and Project Users. Workbench Users will be managed through the Workbench Database, and Project Users are managed through the Crop Database Users table. Each Project user can have several associated project user accounts and the Workbench will provide single sign-on for all.

The workbench administrator should add workbench users with privileges to log on and create projects.

  • When a workbench user creates a project, a local IBDB instance is created for that project with a short name which is unique to the installation and for which the concatenated string of workbench user name plus project name (the project administrator username) is unique in the users table of the corresponding central crop database.
  • A local IBDB instance is created for that project and a MySQL user is created with the project administrator username and a randomly generated password having read access to the central crop database and full access to the local IBDB instance.
  • The project administrator is added to the local IBDB users table with the same MySQL password.
  • As part of the project set up the project administrator can select workbench users or add workbench users and select them to be project members. Usernames, passwords and MySQL accounts are created in the same way as for the project administrator for each project member.
  • The Workbench database keeps track of workbench users, their associated projects, project user names, passwords (and perhaps roles).

There are also two types of project users, 'official users' known to the curator of the public crop information whose identification, authority and credentials are stored with the public data and who have or intend to contribute data to the central public databases. Such data is linked to their identification for attribution and authentication. Then there are 'unofficial users' who have installed the workbench and created local databases but who have not, and may not ever, publish data or who have been assigned credentials remotely (without reference to the central curator). The credentials for unofficial users are stored in the private databases. Unofficial users can be made official by the central curator if and when they choose to publish data.

The Administration tools depend on the authority of the user. For example if the user is the project administrator of the local data resources the he should have a tool to create new users (and hence new projects) with access to that data. If the user has higher authority he should have access to a tool to create new local data resources but initially this will be an installation function of the IBWB.

The USER Table (USERS)

Columns - Long Name (Name) Description Type Length (bytes)
USER_ID (USERID) Unique user identification number Integer 2
INSTALLATION_NO (INSTALID) Number of the ICIS installation to which the user belongsIf zero, the user has access to
any local database up to the level of access privilege (set by central administrator)
Integer 2
USER_STATUS (USTATUS) Status of the user - UNASSIGNED (0), ACTIVE (1), SECURE (2) or CLOSED (9). USERID
can be allocated to a particular installation without being assigned. The local
administrator can then assign them. Thereafter he/she may only close them, and the
sequence is not reversible. SECURE users have their passwords encrypted so that they
can only log on through the Workbench and cannot log on to other users accounts
even if they see the encrypted passwords.
Integer 2
USER_ACCESS (UACCESS) Number indicating the access privilege level of the user. See table below for privilege
levels.
Integer 2
USER_TYPE (UTYPE) Description of user type. For example: (420) Central administrator, (422) Local
administrator, (423) Local User, (421) Guest user, Programmer, Data capture
project, Breeding project, Genetics research, Genetic resources.
Integer 2
USER_NAME (UNAME) Unique user name assigned by the user. Text 30
USER_PASSWORD (UPSWD) Password allocated by the system, but changed by the user. Text 10
PERSON_ID (PERSONID) Person ID linking the user to information such as names, addresses, institute
etc. in the PERSONS table
Long 4
ASSIGN_DATE (ADATE) Date the user ID was assigned as YYYYMMDD Long 4
CLOSE_DATE (CDATE) Date the user ID was closed as YYYYMMDD Long 4

Selected users, such as the central database administrator have full access to the central database and to all local databases. There will also be a "guest user" who will have read access to the central database and to any local database to which physical access is available. All other registered users are linked to a specific installation, with read only access to the central database and varying levels of access to one or more tables of their local database. The user ID, user name, and password will be checked by the open database routine called by all applications, and access to different functions controlled by a system of access privileges.

Access Privileges

Access to the ICIS database is controlled by a USER_PASSWORD and USER_ACCESS privileges. The list of access privileges is given in the table below. The privileges are cumulative so that a user with privilege N has access to all operations controlled with privilege levels less than or equal to N. Anyone starting an ICIS application automatically has access code 10 as a guest user. When a remote installation is allocated, the local administrator, who must be identified, is assigned a USER_ID with ACCESS_PRIVILEGE 100. Local USERIDs may be assigned to local users by the local administrator, and given ACCESS_PRIVILEGES less than 100. The local administrator may not change assignments of these USER_IDs once they have been made, but may change the access privileges of all local users except his own. When the database is opened, the supplied user name and password are checked against values in the USERS table. If valid, the databases are opened. Then the single record from the installation table in the local database is read and a check is made that the user has access privileges for the local database. If not, the local database is closed, otherwise access to individual functions in the middleware is checked against the user's access privileges as calls are made to those functions.

Access Privilege Codes

Code Meaning
10 READ CENTRAL DBMS
20 READ LOCAL AND CENTRAL DBMS
30 ADD LOCAL GERMPLASM DATA RECORDS
40 CORRECT OWN, LOCAL GERMPLASM RECORDS
50 ADD LOCAL SUPPORT DATA (METHODS, CONSTANTS, LOCATIONS)
60 CORRECT OWN, LOCAL SUPPORT DATA
70 CORRECT ALL LOCAL GERMPLASM AND SUPPORT DATA
80 ALLOCATE LOCAL USER_IDS AND PRIVILEGES
90 SUBMIT LOCAL DATA RECORDS TO CENTRAL DATABASE FOR UPDATE
100 LOCAL ICIS ADMINISTRATOR
110 UPDATE central GMS
120 CORRECT RECORDS IN central GMS
130 ALLOCATE USER-IDS FOR REMOTE INSTALLATIONS
140 ALLOCATE REMOTE INSTALLATIONS
150 CENTRAL ICIS ADMINISTRATOR

Configuration

Adaptavist Theme Builder (3.3.3-conf210) Powered by Atlassian Confluence 2.10.3, the Enterprise Wiki.
Free theme builder license