15 Apr 1998 Description of SRE-http's "additional, dynamic" privileges. The "SEL-specific" access control facility of SRE-http is based on matching "client privileges" to the "resource privileges" list associated with the "request selector". This document describes this process, with a focus on the use of "additional, dynamic" privileges. In short: Privileges are granted to a client through several "static" mechanisms, and a dynamic mechanism. These privileges are compared against the "resource privileges" list. A) Static client privileges Assignation of static client privileges is a multi-step process: i) OWNERS (with IP addresses specified in the OWNERS variable) are granted a SUPERUSER privilege. ii) Clients with an IP address that matches (possibly using wildcards) an INHOUSEIPS. stem variable are granted an INHOUSE privilege, and are granted privileges contained in the matching INHOUSEIPS. entry. Actually, they are granted the priviliges listed in the INHOUSE_PRIVS variable (by default, INHOUSE_PRIVS="INHOUSE") iii) If neither i or ii apply, then USERS.IN file is examined. USERS.IN contains, on a username/password specific basis, a privilege list. If this step is required, the client may be sent an authorization request (depending on whether an authorization request header was recieved). Alternatively, a custom USER_LOGON_PROC can be used, which may (or may not) use the USERS.IN file. iv) Everyone (who is given logon access) is granted the privileges listed in the PUBLIC_PRIVS variable. v) If ADD_USER_NAME='YES', then the "username" (or first portion of an INHOUSEIPS. IP address) is added to the client privilege list. For a given client, static privileges are always the same. In contrast, dynamic privileges are granted on a short term basis, perhaps as a function of transient events. But before describing dynamic privileges, a few words on "resource privileges" are in order. B) Resource Privileges Regardless of the source of each of a client's privileges, SEL-specific access control requires that the resource privileges are satisfied by the client's privileges. This "satisfaction" is based on two tests: i) Any of the "ONE_OF" resource privileges are satisfied ii) All of the "MUST_HAVE" resource privileges are satisfied. Basically, the ONE_OF resource privileges are "or" conditions, and the MUST_HAVE are "and" conditions. Satisfaction of all the MUST_HAVE resource privileges is a necessary, but not sufficient, condition -- at least one of the ONE_OF resource privileges are required. Note: if there are no ONE_OF conditions, it is assumed that the "ONE_OF conditions are automatically satisfied" (the same can be said if there are no MUST_HAVE conditions). As an aside: The "resource privileges" are determined using: "SEL-specific" entries, and "REALM-specific entries" in the ACCESS_FILE (see ACCESS.IN for details). In addition: If ADD_RESOURCE_NAME='YES', the "action" portion of the "request selector" is added, (the "action" portion is the part of the request selector before the first ? character). Thus, a request selector of STARS/RIGEL.HTM would yield a "resource privilege" of STARS/RIGEL.HTM. C) Dynamic Client Privileges Now, let us consider dynamic privileges. The notion underlying dynamic privileges is that one might wish to grant conditional access to server resources, where the condition is a function of recent history. For example: i) you want clients to fill out a registration form before giving them access to a set of data files, with the registration good for a limited time span (say, 30 minutes). ii) you wish to enforce a particular order in viewing linked documents, with no "skipping ahead". iii) you have an images archive you're happy to give away, but you don't want lazy websters to include links to these images in their web pages. All these cases can be easily handled through the use of dynamic privileges. Dynamic privileges are granted by adding entries to a "dynamic privileges" cache. To use this cache, you first have to make sure that the SRE-http variable CHECK_ADD_PRIVS='YES'. This tell SRE-http to "store, and check, additional privileges". Assuming that CHECK_ADD_PRIVS='YES', entries can be added to the "dynamic privileges" cache in two ways: 1) Inclusion of a keyphrase in a server-side-include capable HTML document, where: new_privs : a space delimited list of the "dynamic privileges" you wish to add duration : number of minutes these dynamic privileges will be available. Basically, for the next "duration" minutes the "new_privs" privileges will be added to the "client privileges". These dynamic privileges are cumulative -- the client can accumulate a number of "dynamic privileges" by requesting documents containing varying INTERPRET FILE ADDPRIVS.RXX statements. 2) Calling the SREF_ADD_PRIVS procedure from an external procedure. SREF_ADD_PRIVS should be called as: status=sref_add_privs(new_privs,duration) Where new_privs and duration are as above. In both cases, when the client makes a subsequent request, the "dynamic" new_privs are added to her static privileges. *** Actually, the dynamic privileges are based on the client's IP address. *** Therefore, they can be assigned to any individual -- even if there is *** no entry in SRE-http's username database (USERS.IN) for the client. Note: for security reasons, a slightly modified version of the new_privs are added -- the ADD_PRIVS_PREFIX is appended to the front of the new_privs. This is done to prevent unscrupulous individuals with limited access to your site (i.e.; the right to put documents in "personal" directories) from subverting access controls by sneakily requesting documents that contain: D) Examples An Example (assuming that ADD_PRIVS_PREFIX='!'): Assume the following access-control entries (in ACCESS.IN) TEST/F1.HTM !P1 TEST/F2.HTM !P2 and a T1.HTM file which includes the statement: and a T2.HTM file with A request for T1.HTM will cause a !P1 "dynamic privilege" to be added to the client's privilege list (for the next 10 minutes). Within this time period, a request for F1.HTM will be honored, while a request for F2.HTM will be not. On the other hand, a request for T2.HTM will enable subsequent access (for the next 20 minute) to both F1.HTM and F2.HTM. Notes: i) SREF_ADD_PRIVS also can be called with extra arguments, such as other IP addresses. The full form is: status=sref_add_privs(new_privs,duration,verbose,port, host_nickname,user_address,enmadd) ii) The dynamic privileges are stored in _ADDPRIVS.80 (or .nnn, where nnn is the server port) in the GoServe "working" directory.