UBNS

netAuth has a built-in mechanism to support UBNS. All connections to a specified service from user $U_i$ can be served by a single server process $p_i$ unique to that user. For users $U_j$, for which there does not exist a corresponding process $p_j$, a listening process $p$ pre-accepts (see Section 4) the connection and creates a new process $p_j$⁶. Figure 1 shows two types of queues of unaccepted connections maintained by netAuth (one for new users and the other for users for which there exists a user process).

Figure 1: mapping all the connections of a user to the same process

Figure 2: calendar privilege separation example

Per user server processes are created on demand for efficiency and flexibility. Successive connections for $U_i$ will reuse server process $p_i$. NetAuth can also support other commonly used methods such as pre-forking processes or forking a process per connection.

This mechanism provides a very clean programming model as it is trivial to create back-end services for each user on demand. For example, Figure 3 shows a calendar proxy which caches a user's local and remote calendars (and no one else's) and provide feeds to a desk planner, email to calendar appointment program, a reminder system, etc. The reminder mechanism might know where the user is currently located and where the appointment is, so that reminders can be given with suitable lead times. As the user's connections are always to the same process, requests are serialized for that user preventing race condition (and the need to synchronize) and enable easy adding of calendar applications without configuring for security (since the configuration is in the proxy). Such a model also allows different parts of the application to execute on different systems. For example, a user interface component could run on a notebook, and a backend store could run on an always available server.

We next look at the uses of NetAuth in more detail.