Notes on User Authentication

2 March 1999

1. In order to use ITX software, including directory services, all users as well as server applications must authenticate themselves with directory services, once per application. They do this by passing their username and password to the DesktopSignaling constructor, which will then call declareIdentity with it. For human users (i.e. not server applications) the userid and password would best be collected via a dialogue box. Yang will write a Java-based Dialog that applications can call when first starting up.

   At present, declareIdentity doesn't return a token or anything; it simply throws an AuthenticationException if the PIN is invalid. If valid, the DirectoryServices retains a flag saying that this instance of DirectoryService was validated for the given userid.

   It was decided that DesktopSignaling will create the DirectoryServices instance on behalf of the application. The application can get a handle to this instance by invoking DesktopSignaling.getDirectoryService().

2. There is a slightly modified design for the Location object. It now has four fields:
   • IP address - the hostname of this Location, null if not known
   • port number - the port on which DesktopSignaling is listening
   • Redirect string - userid (email address, application name, telephone number, extension number,...) to which the call should be redirected
   • Application string - name of the application running at this location

   Thus Directory Services will provide "get" methods for these four things. There is already sufficient data stored in a Location string to support these 4 methods.

3. Merging two LocationLists obtained from two directory lookups (one on userid and one on "signalingsrv") is clumsy and inefficient. Instead, we will do away with the "signalingsrv" entry in the database. Each user record will contain dynamic Location objects that contain the IP and port number of DesktopSignaling components in currently running applications, IF the user is currently running a desktop telephony application that is dialable.

   Users might launch applications that do not go into the LocationList for that user. Such an application cannot be dialed, but it can still place outgoing calls.

4. We dial a user by calling DesktopSignaling.Dial(name). Signaling looks up the name using directory services:   LocationList list = lookup (name)

   For example, suppose we want to call "mumble@cs.cornell.edu". Here is an example of a LocationList that might be returned by Directory Service. For Locations with an IP and port, signaling can just send an invite packet to that port. There is a peer signaling component listening there. If there is no IP and port number, then signaling effectively does a Dial(RedirectString). To avoid circularities, this may be limited to one level of redirection. Here is what might be on the LocationList, in the following order:
    Roaming Location: Location of dialable application most recently launched by user "mumble". Contains IP:port
    Dynamic Location List: Locations of other running dialable applications at which this user may be reached. These all contain IP and port numbers too.
    Custom Location List: schedules; if there is a time match, a Location List is returned (or just one Location?)
    Default Location List: other locations where user may be reached, in decreasing order of preference. These are strings, which might be telephone numbers, email addresses, application names, etc.

5. It was proposed that a LocationList is a list of locations plus a boolean flag, "autoDial". If autoDial is true, then signaling will not invoke the SignalingObserver's chooseUser() method because the Locationlist is just the gateway list. Directory Services sets this true ONLY when its lookup argument was all digits and was not in the directory.
6. Madhav has asked that the LocationList being returned by DirectoryServices be manipulated so that each phone number has been replaced by a Gateway LocationList, etc. We feel that this is better done in DesktopSignaling.

   While a recursive approach could be used to traverse the LocationList, expanding user strings as it goes, it was decided that checking for infinite recursion would be too difficult.

   Therefore, we decided that DesktopSignaling will expand Location objects just once. That is, if someone is trying to reach me, and if the next Location on the LocationList to be tried happens to be an email address, DesktopSignaling will look up the LocationList associated with that email address and invite Locations on that list, but only if they have a hostname and port number. It will not expand that list further.

7. Use hostname, not IP address, in anticipation of DHCP.
8. Applications register as a string without an "@" in it. Its LocationList is the list of places where that application is currently running, not "could be running". DesktopSignaling handles the registration of these applications.   Issue: must all of these applications be pre-registered via management, or can they register themselves "on the fly"?
9. When DesktopSignaling.Dial(s) is invoked where "s" is all digits and "s" is not in the database, DirectoryServices's getLocationListByID returns the LocationList associated with "gatewaysrv". The LocationList in this case will be the hostname:port of each GatewayDesktopSignalling that is running. LocationList.autoDial() is true.

   ---