Re: passwords and ref's

Gary Dietz (gdietz@wpine.com)
Wed, 06 May 1998 14:26:04 -0400


At 11:06 AM 5/6/98 -0500, Jason Williams wrote:
>On Wed, 6 May 1998, Steve Berry wrote:
>> i like the new ver of cornell cu-seeme for win95 but the prob is some ref's
>> that i visit need a password and i do not see how to put one in for loging
>> on to them. how can this be done or can it?
>
>As far as I know, it can't. You CAN use Conference IDs just fine, but
>passwords are a White Pine only feature for now. I still think that any
>public reflector that requires passwords isn't thinking of the people who
>use their reflector.

If someone running a "public reflector" is using passwords, they probably
have a reason!

In situations other than public "video chat" password protection, and even
more detailed conference access methodologies (like those begun to be
implemented in MPCS--the User Database) are constantly being demanded.

Case 1) Public video chat where a server monitor wants to schedule a
conference that they can be sure nobody will find. Hidden conference is
useful, but not always the most secure.

Case 2) Private servers with multiple conferences where the operator WANTS
CU users to see the name of the conference, but doesn't want to allow them
to joing the conference until they send an e-mail requesting access

Case 3) Any distance learning environment where the politics of a school
district demand a higher level of security (still never any guarantees -
but they like to add the most security they can)

Conference level password protection is available in WP CU clients. MPCS
has user level protection as well. Its pretty cool... Here's how it works
from a user's point of view:

The conference administrator sets up a database of users, each with their
own User ID and password. You can then associate a set of users with a
specific conference.

When it comes time to log in, the participant goes to a specific MPCS web
page. They enter their user ID and password. When they are authenticated,
the are admitted to the conference in a "one time admit" command, and can
then fire up a client (CU, NetMeeting, Intel Business Video) and connect to
the conference they were autheticated for. Attendees who are not
authenticated will not be able to connect.

Another methodology which allows for some level of conference security is
scheduling. If you schedule a conference to be enabled from 8am to 10am
EST, then clearly nobody can connect at 4am because the conference is not
even enabled.

ClassPoint takes the security intergration a bit farther. No ClassPoint
clients can EVER connect to the server unless they are entering through a
web page. Once the ClassPoint Student or Instructor is verified by UID and
PW, an on-the-fly file is sent to the ClassPoint client which allows it to
start and connect to the server.

Conclusion: Various levels of video chat customers require different
levels of conference access securtity.

Regards,

Gary

-------------------------------------------------------------------------
Gary Dietz, White Pine Software, Incorporated.
ClassPoint(tm) http://www.wpine.com/classpoint
CU-SeeMe(R) Videoconferencing http://www.wpine.com/cuseeme
MeetingPoint(tm) Conference Server http://www.wpine.com/meetingpoint
Global Schoolhouse CU-Schools http://www.gsn.org/join
-------------------------------------------------------------------------