A hierarchical, systematic directory structure will be utilized in order to allow a simple mapping of URI to authorization entity:
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.
The udcapture_class table contains definitions of each class for which the system maintains a media directory:
Access control lists for each class exist as tuples in the udcapture_ace table:
Authorization proceeds as a simple SQL query:
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:
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.