next message in archive
no next message in thread
previous message in archive
Index of Subjects
James and others were recently discussing the issue of REMOTE_USER vs.
REMOTE_IDENT. Here is the definitive "draft" explanation. There was little
discussion in subsequent notes, in my recollection. but there appears to
be work that remains to be done!!!
I serendipitously came across this note (in hardcopy) from Gerard which
explains it all, and should be incorporated into some DOCUMENTATION!!! so
new sys ops (not to mention ourselves :) will know how it works. Note
that there is lots of useful stuff here for the documentation side, and
some policy issues that need to be reviewed, so there may be future
revisions, both on our site and distributed sites.
The original was posted to CCN-TECH and CCN-PIC, but the former archive
seems to have been broken at that time, so I will paste it in here, as
most of us do not have access to the latter.
Ed Dyer aa146@chebucto.ns.ca (902) H 826-7496 CCN Assistant Postmaster
http://www.chebucto.ns.ca/~aa146/ W 426-4894 CSuite Technical Workshop
Religion Page Editor, Chebucto Community Network http://www.chebucto.ns.ca
---- entire article (reformatted) ----
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 <editors>
> 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 the "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 manage 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-user" 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
anyway.
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
address 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 (notes 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-disclosure" 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 with 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 Volunteer 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 are added to the appropriate mailing lists, etc.
6. If document editing privileges need to be granted, Volunteer
Committee informs the 'editors'
7. Volunteer Committee runs an orientation/training session for
the user, and at that time tells them what their secure access password
is.
8. Granting "maintenance" access will require additional input (by
Volunteer Committee or by an existing 'htgroup' member?).
Lots to think about. Let's hear some opinions.
4
- Gerard
next message in archive
next message in thread
previous message in archive
Index of Subjects
next message in archive
no next message in thread
previous message in archive
Index of Subjects