Administration

Overview

Security for student database accounts is integrated with LDAP support for e-mail and other services that can use LDAP for authentication. Users of the student database need an account configured with the database service, combined with permissions to access data entry forms.

All services associated with each 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 that affects which forms can manage which accounts. Accounts configured with services having a high access level are not manageable from forms designed to manage lower-level services. 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 low-authorization user from changing the password and then using an account with more access.

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 these forms. The User Access form is used to manage this information, which is expressed in terms of form groups, or individual forms.

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

Sessions

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

Sessions can exist prior to authentication being completed; this allows the user name and password to never cross the network clear-text. Authentication is completed when the session cipher is correctly generated by both client and server. Incomplete 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 thirty minutes of inactivity. Any exchange of information between client and server will keep a session from timing out, including the row lock maintenance that occurs every 60 seconds.

The Currrent Sessions form shows a summary of all sessions, including any that are incomplete 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 what privileges on each object must also be specified. The server-side code checks each interaction with a form to verify that the requested action is allowed for the data being manipulated, e.g. whether a form is allowed to update information from 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 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.