** Reply to note from "S. Hayles" <[log in to unmask]> Wed, 15 Nov 2000 16:00:38 +0000 (GMT)
Yo bro, you could have had something easier to ask :-)
Here are a few thoughts to help (I hope) in answering some questions. Sorry
for the style of the narrative I am in programming mode and writting
understandble English is difficult :-)
When creating web sites (making information available if you like) start from
the premise that ALL information should be available on the WWW. HTTP
technology was never intended to be closed so it is geared into having
material freely available. Thus the problems you are having. You will
probably find much less material has to be "locked" if you follow the
above approach.
Other Employees
---------------
IP protection is not much good anyway (IP address can be faked and may even
translate in your DNS? NDS? whatsit). I seriously doubt the confidentiallity
of the material that you are prepared to open to all your students but not to
other people working within your campus. Further, how come and your "other"
users within the campus can use a computer with a university IP address? (if
you like a University managed computer as the university gives it an IP
address).
Your existing staff and students are just as likely to "pinch" material from
your site and pass it on.
Other Students
--------------
I guess they can use public terminals and access your web site. Uhmm,
so what :-)
=============
In my little mind I do not see what it is you can have fully open to all
within but not to outsiders? Here is what we do.
Teaching material may be protected by IP or individually set up (by users) ACL
password files (I cannot speak for it as I don't look after that side of
things).
Centrally provided student related guidelines etc are open for the WWW. We
don't mind scrutiny.
Centrally provided general staff (or student) guidelines are open too.
When we come to confidential material comittee minutes, agendas, working on
the RAE, or working on Financial Planning etc. there are two levels of
password protection. All staff (from cleaners to the Principal) can access
the staff areas, IDs exist and can be given to anyone who wants access.
However, where we work for the RAE (my other job :-) only certain predefined
users can access the information. (look at group files in your protection set
up directives)
All the information whether domain or password protected can be accessed from
outside the university with ID+passwords.
(We have not yet implemented an ID+password system for students).
It works :-)
Some more techie stuff
Passwords
----------
Passwords are easy to set up and even run them with identical "processed
files" accross multiple servers that obbey the Unix http standards (ie. not
Micro$oft). [If you would like more info contact me off line.]
For students you probably already have a matric number + email name or Date of
Birth or .... that can give you the combination of UniqueID + password.
For staff you just create them and issue them. No big deal.
Applying protection
-------------------
Don't lock individual directories as users set them up at will ( that is by
applying individual protection directives for each directory the user wants
to protect). Set up a mechanism of two, three (as many as you need) setups
which define, eg. any directory beyond a dir=/do/ will be domain only (ie. ip.
protected) or /pp/ for password protected.
thus your URI=myserver/dept/do/this/that/file.html
will be accessible at /dept/ but IP protected passed /do/
Then it is up to the users to consider how they organise the material. What i
am saying, is we organise round the protection directives and not round the
material.
Use of ACLs
-----------
You could get round the above example and protect individual files, have
1000s of different IDs+passwords. Nightmare in my view, not to be centrally
encouraged. Further ACL files may be sitting in http accessible areas (loads
of protection that would offer).
Use of LDAP or similar authentication as for example with IIS from M$.
----------------------------------------------------------------------
Serious security risk, say no more. Even more complicated if some outside
users must access some internal areas.
> We could put password protection around University only data, but then
> access is restricted to members of the University registed with
> the Computer Centre, plus users have the inconvenience of another
> authentication per session.
Why should they register with the Computing center? You don't have to run IDs
+ passwords that can access the underlying (file) server. The http daemon can
use its own passwords and better if it does as it is less of a security risk
and administrative headache ... I got about 5000 of them. I generate
UserID+random passwords on the basis of information I exctract from personnel
records.
=================================
I am aware in all this lenght I have not answered your question. What I am
trying to say is change the parameters of what you define as a problem. With
your current definition, I agree, it would be very difficult to solve.
One techonology you could look at would be dynamic IP addresses issued on the
basis of who is the user of a computer ... I don't know if can be done it
might work.
Looooong or what?
Take care.
Charles
==============================================
Charles Christacopoulos, Secretary's Office, University of Dundee,
Dundee DD1 4HN, Scotland, United Kingdom.
Tel: +44+(0)1382-344891. Fax: +44+(0)1382-201604.
http://somis.ais.dundee.ac.uk/
Scottish Search Maestro http://somis2.ais.dundee.ac.uk/
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
