HTTP Authorized Access (was Re: Criteria for using the IPDb) Date: Mon, 8 Jul 1996 07:26:56 -0300 From: Gerard MacNeil Organization: Chebucto Community Net To: Christopher Majka CC: CCN-TECH , aa050@chebucto.ns.ca, References: next message in archive next message in thread previous message in archive Index of Subjects Christopher Majka wrote: > > Hi! > > Can someone tell me who can use the IPDb? Are the members of > automatically scripted to allow egress or do we do this manually via a > by-request basis? Up to this time, I have added users manually. My "quick and dirty" methodology was to "paste" the 'login:encryped_passwd' from '/etc/master.passwd' and append it to '/ccn/etc/ht passwd'. It is the entry in the latter file that grants access to CS_INFO/adm. To access one of t he "maintenace" groups (currently there are three - office, member, ip), the login needs to be added to the appropriate line in '/ccn/etc/htgroup'. Check the docs at NCSA on Authorized A ccess for a more complete explanation. The management of 'htpasswd' and 'htgroup' needs some discussion. Background: With the NCSA HTTPd distribution, there are a couple of utility programs to man age these files. Only one has been implemented (change your secure access password) which is a ' C' program that needs to be compliled on each host. Hard-coded into the program is the definit ion of a "WIZARD" (I think) name - specified as 'aa000' on CCN - and password that is the "super-use r" for the files - ie., this user_name has the ability to to change the password other "names", ad d new "names", etc. Other distributed functionality was not implemented since I was doing it all an yway. As implemented on CCN, the "name" in the 'htpasswd' file is the user's login. As a technical note, in CGI programs, there are two variables that come into play. REMOTE_IDENT, wh ich is the login as reported by the users host site, is "unreliable" since depends on the host runn ing "identd". If the host is not running "identd" (CCN does), REMOTE_IDENT is set to "unknown". When the user accesses a directory protected by HTTP Authorized Access, REMOTE_USER is set to the "name" entered, verified by matching the "name" and "passwd" with the entry in the HTTP passwor d file (the afore mentioned 'ccn/etc/htpasswd' on CCN). The practice of using the CCN login as the 'htpasswd' name started as an "easy" way to add CCN users to the 'htpasswd" file. It is now a requirement for CSuite for two reaso ns: 1. REMOTE_USER is recorded in log files as the user who made a "mainten ance" change 2. mail is sent by some programs from REMOTE_USER - which means it must be a legitimate login ID so "replies" do not bounce. Discussion: There are technical, policy, and usability implications to this set-up. Technical: Two issues: 1. Documentation for CSuite distribution - we need to let CSuite hosts know how it is supposed to work. The documentation on Authorized Access from NCSA covers all the technical details. It is the importance of the 1:1 relationship between login ID and 'ht passwd' name that is CSuite specific. 2. Implementation of the other NCSA utility programs - which would addr ess Chris's question and enable volunteers to manage 'htpasswd' and 'htgroup' through the interface. My recommendation would be to assign the responsibility to manage these files be placed under the CCN Volunteer Committee. Policy: Several very complicated issues - depending how you look at it 1. As implemented, there are two levels of Authorized Access. There is "Read Only" access, which only requires an entry in 'htpasswd'. This functionality is implemented on the main administration screen, and lets the authorized user view the information in the NAMEDB (user membership information), IPDB (Information Provider information) and NOTEDB (no tes on users and IPs), and provides access to the "office" and "editors" archive. There is also "Maintenace" access, which requires the user to be in the appropriate group. There are curr ently three: member: Activate user accounts and maintain user membership records Change user passwords office: Record receipt of IP Agreements Money stuff (banking, invoices, etc) ip: IP database details Create IPs The question becomes *who* gets access to *what* functionality. 2. Second question: How is the "who" and "what" determined? The inform ation in the databases must be considered confidential (I know some marketing organizations would love to have the info). Some months ago I initiated an effort to have a policy formulated w ith the intent of having a "non-disclosure" statement, and appropriately it was taken on by the C CN PIC. Inasmuch as that Committee has just got a new Chair, the task remains unfinished. To date, it has been either David T.'s or my own personal judgement. 3. Third question: What volunteer team should have the responsibility t o "vett" users (ie. confirm they honest and honourable)? My recommendation is that this be a share d responsibility taken on by the various Committees responsible for the information: office -> CCN Board of Directors member -> CCN Membership Committee ip -> CCN Information Provider Committee In general, I recommend that any user first be granted "Read Only" access, and at a later time be granted "Maintenance" access. 4. Fourth question: What volunteer team has the responsibility for impl ementing the "who" for "what"? This is where it really gets complicated. I would recommend that the Volunteer Committee (now that I'm on it ;-) be assigned this responsibility. But how is the communication supposed to flow: user -> ?? Committee; ?? Committee -> Volunteer Committee; Vo lunteer Committee -> user Usability: The way I look at it (take this as first draft only): Let us assume that we have a policy on access to the database information. It details the requirements for access, the procedure for vetting, and the signing of a "non-d isclosure" statement. A user expresses an interest in joining a volunteer team (say userhelp) that is responsible to a Committee (CCN Support and Training). What needs to be done? 1. Volunteer Committee sends email to the responsible Committee/Team wi th information on the prospective volunteer 2. The Committee/Team follows the proscribed vetting procedure 3. The user signs the "non-disclosure" statement, and and gets it to th e CCN office 4. On receipt of the "non-disclosure" statement, the 'office' (through a form submission) updates the users NAMEDB record (new data fields) and email is sent to the Volu nteer Committee (and is simultaneously informed that the volunteer has been accepted - an essential piece of feedback) 5. The Volunteer Committee adds the user to 'htpasswd', ensures they ar e added to the appropriate mailing lists, etc. 6. If document editing privileges need to be granted, Volunteer Committ ee informs the 'editors' 7. Volunteer Committee runs an orientation/training session for the use r, and at that time tells them what their secure access password is. 8. Granting "maintenance" access will require additional input (by Volu nteer Committee or by an existing 'htgroup' member?). Lots to think about. Let's hear some opinions. - Gerard next message in archive next message in thread previous message in archive Index of Subjects