Administration

Overview

Security for student database accounts is integrated with LDAP support for e-mail and other services (see LDAP Integration). Users of the student database need an account configured with the database LDAP Service (DB) and permissions to access data entry forms.

All services associated with an LDAP account share the same password, which introduces some restrictions on where management of accounts can occur. Each LDAP Service is defined with an access level used to determine how forms can manage accounts. Accounts configured with services having an access level exceeding a specific form's designation will not be updatable on that form. The E-Mail Account form, for example, will not allow management of an account with access to the student database (a service with a higher access level). This is necessary to prevent a lower-authorization user from changing a password to gain access to an account with a higher authorization level.

Accounts

Each person in the database can have multiple LDAP accounts. Access to the student database is managed with either the Database User or LDAP Account forms. Both can create and manage LDAP accounts and the database service.

Database users must also have their security defined in terms of what forms they have access to, and what type of access they need to those forms. The User Access form manages this information, which is expressed in terms of Form Groups or individual Forms.

Revoking database account access can be accomplished by disabling or deleting an account's database (DB) service. The change is immediate.

Sessions

When a database user correctly authenticates with the SIS, a session is created that contains the details needed to maintain secure communication between the web-based client and the database server. This information includes the account's login, the last time the session was used (to determine if a session has timed out and authentication needs to occur again), and the cipher used to encrypt all client-server communications.

Sessions can exist in a partially defined state prior to authentication being completed (which occurs when the session cipher is correctly generated by both client and server). The session is created when a user is prompted to log in, and updated as the authentication attempt proceeds. Note that the login and password never cross the network as clear-text; the client and server independently generate the cipher, using shared knowledge of session information to do so.

Partially defined sessions will only linger for a short time; authentication must be completed within thirty seconds of initialization, or the session will be discarded and the authentication sequence restarted.

Authenticated sessions time-out after a short period of inactivity (as specfied on the Organization form). The web client will close all forms and log out after this period of inactivity has elapsed. A similar process exists on the server to remove stale sessions, but any exchange of information between client and server will keep a session from timing out, including the row lock maintenance that occurs every sixty seconds.

The Currrent Sessions form shows a summary of all sessions, including any that are partially defined or have timed-out.

Forms

Each form is defined with a code, label, description, and URI. The list of database objects (tables, views, etc.) that the form requires, and the privileges for each object must also be specified. The server-side code checks each interaction with a form and user to verify that the requested action is allowed for the data being manipulated, e.g. whether the user and the form are allowed to update information in database table x. Form and Form Objects can be used to manage this data, but it is typically defined and maintained by developers when forms are added or modified.

Form Groups

The hundreds of data entry forms that exist in the student database are organized into functional groups to assist with provision of access to users. Rather than having to specify each individual form that each user needs, it's possible to specify them by group.

Each form group specifies a list of forms and overall permissions for the group. There is a group called VALID.V, for example, that allows viewing of all validation tables. It contains all of the database validation tables and is configured with select access, but not insert, update or delete; this allows viewing of data but no modification. The Form Groups form can be used to manage these groups, but they are typically defined and maintained by form developers when forms are added or modified.

The User Access form is used to assign form groups to users. It can also be used to extend or revoke access to individual forms.

Reports

Each Report is configured with a code, description, and URI. The list of parameters used by each report are specified with a name, whether a parameter is optional, and any default for each parameter.

Access to reports is controlled by access to the forms they are requested from. No additional user-specific security restrictions are imposed.