Directory Structure

A hierarchical, systematic directory structure will be utilized in order to allow a simple mapping of URI to authorization entity:

/[term]/[subject code][catalog number]/[section]

Further division at the subject code and catalog number boundary is feasible, but may be overkill. In some instances, no section may be necessary (e.g. if there is only a single section or the same professor teaches all sections and reuses the same media for all of them).

Reverse mapping from class identification components to a relative URI is a simple textual composition: no intermediary data or lookups are necessary since the correlation is absolute and direct.

As past terms "time out" and need to be removed from the system, a simple deletion of a top-level directory is involved.

Database Components

The udcapture_class table contains definitions of each class for which the system maintains a media directory:

CREATE TABLE udcapture_class ( classId INTEGER PRIMARY KEY AUTOINCREMENT, term CHARACTER(4) NOT NULL, subjectCode CHARACTER VARYING(8) NOT NULL, catalogNumber CHARACTER VARYING(10) NOT NULL, section CHARACTER VARYING(4) );

As mentioned, in some instances a course may not have multiple sections or the professor teaching all sections may elect to share media among all sections: in such a case, the section field would be left as NULL.

Access control lists for each class exist as tuples in the udcapture_ace table:

CREATE TABLE udcapture_ace ( classId INTEGER NOT NULL REFERENCES udcapture_class(classId), udEmplid CHARACTER VARYING(11) NOT NULL );

Note that the enrollees' UD ID (or employee id as it's also known) is used: using UDelNetId would leave the system unusable for one day for any person who changes his/her UDelNetId. The means by which a user's UD ID is made available despite his/her authenticating against LDAP using UDelNetId is discussed later.

Authorization proceeds as a simple SQL query:

SELECT COUNT(a.udEmplid) AS authz FROM udcapture_ace a, udcapture_class c WHERE c.classId = a.classId AND a.udEmplid = '19516' AND c.term||c.subjectCode||c.catalogNumber = '2101CHEM101' AND c.section = '010'

The final predicate would not be present for URIs containing no explicit section. If the returned authz field is non-zero, then the user with UD ID 19516 is authorized to access the URI /2101/CHEM101/010.

The table definitions above are made with repect to SQLite3; it's quite possible that before all is said and done, Postgres will be setup on udcapture and other aspects of the system (the media dropoff handler for one) will be modified to use the same (single) database.

Apache Authentication and Authorization

The authentication phase in Apache will be handled by the stock mod_authnz_ldap. The end user will enter a UDelNetId and password when prompted by the browser. From there, mod_authnz_ldap will search for an LDAP directory for which the uid attribute matches the UDelNetId. If found, the module attempts to bind to that directory using the supplied password. If successful, the user has been properly authenticated.

Providing multiple attributes in the AuthLDAPURL configuration directive to mod_authnz_ldap implies that for all applicable URIs, the username provided by the browser will be matched to the first attribute; all additional attributes will have their values added to the request's subprocess environment table (the subprocess_env field of the request_rec structure, which is exported to the environment of all subprocesses spawned by the request). The variables are all named as AUTHENTICATED_[ATTRIBUTE]; for example, udEmplid would appear in the environment as AUTHENTICATED_UDEMPLID. The following URL authenticates by UDelNetId but also adds the employee id returned by LDAP to the environment on a successful authentication:

ldap://ldap.udel.edu/o=udel.edu?uid,udEmplid TLS

Authorization can proceed by any supported mechanism. A flat file or dbm file containing class access lists as "groups" is feasible but would require explicit per-directory configuration via .htaccess files. Checking LDAP group membership could be used to grant access to specific UD "projects" but would again require explicit configuration. One reason for adopting a systematic structure to the web directories is that an Apache authorization module could automatically decompose the requested URI into the individual fields necessary for an SQL query: the mere presence of an aptly-named directory is the only configuration (if it can be called that) involved. With LDAP authentication providing the employee id via subprocess_env, everything necessary to authorize against the udcapture_class and udcapture_ace tables is present. The only configuration really necessary would be made to the root directory of the class hierarchy to enable our authorization module.

The specialized authorization module will be named mod_authz_udcapture. Modules which perform authentication only are named with a authn component; modules like ours which only authorize use a authz component; and modules which will do both get a authnz component.