[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference forty2::x500

Title:	X.500 Directory Services
Notice:	Sprt: FORTY2::X500_SUPPORT, Kits: 216.*, try dir/titl=OFFICIAL
Moderator:	FORTY2::PULLEN

Created:	Tue Jan 30 1990
Last Modified:	Thu Jun 05 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	1016
Total number of notes:	4299

984.0. "Infobroker and Access Controls" by CHEFS::rasmodem27.reo.dec.com::Herbert () Thu Mar 13 1997 20:39

A customer is setting up a corporate X.500 directory with employees accessing 
it via web browsers and InfoBroker. They would like to implement access 
control so that individuals can modify certain attributes of their own 
entries.

Standard requirements so far. However, they do not want to implement "yet 
another password for people to remember and forget".

Has anyone any suggestions for implementing access control on modifying
entries via web browsers without the user having to supply a password?

The customer was wondering if any user id information was passed in http which 
could be used on the server.

thanks,
	Paul.

T.R	Title	User	Personal Name	Date	Lines
984.1		a-113.tunnel.crl.dec.com::FORTY2::PALKA	Andrew Palka Altavista Directory	`Fri Mar 14 1997 11:58`	28
	The Web browser can probably send some kind of identification string, however it is certainly easy to arrange to send any string you like. So if the string is some kind of user name (without password) then it would be easy to impersonate anyone. Whether the Web server can be persuaded to look at the identification string and convert it into some kind of x.500 name is doubtful, and without a password it would not be secure anyway. There are only 3 ways that I can see this working. 1) change the browser so that it can send some kind of configurable identification which includes the password, and change the web server to convert this identification into an x.500 name and password. 2) Change the web server so that it can send a 'login' screen to the user. Once the user has logged in the web server sends a cookie back to the browser, which retains it indefinitely. The web server can then use the contents of this cookie to generate the authentication information for the directory access. 3) Implement single login in the network. This is the only really satisfactory way to do things, but there is no widely accepted standard for doing this. Unless it is available in just about everything it wont fly. (Kerberos is a start, but not the complete solution). Andrew
984.2		FORTY2::TATHAM	Nick Tatham @REO	`Fri Mar 14 1997 17:11`	10
	Check the InfoBroker web browser config file. You can restrict which attributes can be modified if I remember correctly. I think this means that you can run access control so anyone can modify anything, but only give them web access and only allow them to change telephone number. They'll still go through the password screen but will be able to type submit without a password. Tacky but might work. Nick
984.3	Digital Certificate	NETRIX::"barnettd@mail.dec.com@"	David Barnett	`Sat Mar 22 1997 01:53`	9
	Ron Rivest (RSA, MIT) recommends the use of digital certicates as a means of authenticating identity. Both Netscape Navigator and MS Internet Explorer support certificates, and point you to the VeriSign(www.verisign.com) site to get one. One of our partners, Entrust Technologies (www.entrust.com), has a Web/CA product. A digital certificate is the equivalent of a password/logon ID combination. The user just has to install it in the browser, and it authenticates identity to the web server in the background(if configured to do so). [Posted by WWW Notes gateway]