Proxy and State Servers

Large, multi-processor WINPHO servers are maintained in Sacramento. In addition to these centralized servers, smaller platforms are deployed in the field. These field servers act both as proxies on the network and in-state hubs, facilitating efficient use of bandwidth [i] . To date, we have been able to use one server per state, with that unit accommodating both processes. However, should server load increase to the point where a single unit cannot serve a state's needs, we will add CPUs or simply upgrade to more robust devices.

As the term "proxy" implies, these servers stand-in for other devices on the network, making the system more efficient. For example, the Orange County Sheriff's Department (OCSD) shares over 500,000 mugshots through WINPHO. While an index to the OCSD's collection is stored on the main WINPHO server, as are thumbnails of all of OCSD's records, the full resolution mugshots themselves are stored on and retrieved by WINPHO from the OCSD server in Santa Ana, California. When requesting mugshots from the OCSD server, users are checked against the list of authorized users maintained on that server. Although this arrangement works very well for internal OCSD use as well as a small number of external users, it becomes unwieldy quickly. Given the potential number of WINPHO users requesting mugshots, the task of simply keeping the list of authorized users current would be unreasonable. To avoid this problem, OCSD has agreed to rely upon the WINPHO server's security.

Every agency that contributes to WINPHO remains in control of its own data, and each agency's rules having to do with access to that data are enforced by the WINPHO server. As discussed elsewhere in this document, this means that not all WINPHO users have access to all WINPHO data. For instance, under state law, Oregon Driver License records are available only to sworn law enforcement officers through WINPHO. Correctional Officers (COs) at the Sixth Avenue Correctional Center in Anchorage, regardless of their status in Alaska, are considered by Oregon DMV not to be sworn officers. Therefore, WINPHO does not allow Alaskan COs to view Oregon DMV records. In the same way, no WINPHO participant allows a DMV unrestricted access to a mugshot. Therefore, Oregon DMV employees are currently unable to view any data but their own on the system.

By using the WINPHO server to authorize users, administrators avoid the need to keep current lists of all authorized users on every system connected to WINPHO. Rather, each agency shares with WIN the criteria used for deciding whether a certain type of user will be granted access, and then trusts WIN and the WINPHO server to exclude all who do not meet their standard.

In practice, a user who is properly logged into WINPHO is only presented with a choice among the systems that he or she is authorized to use. Thus, in the case above, a CO in Alaska is not even shown the link to Oregon DMV. Having excluded all inappropriate users from the process, the WINPHO server subsequently routes all requests for access to an external system through a proxy, and the proxy presents the external system with a properly formatted request. In doing so, the proxy logs into the external system as WINPHO. Because that external system trusts WINPHO to exclude all unauthorized users, it fills the request. As noted above, this means that the administrator of the external system need only maintain one account for all WINPHO users. Conversely, it means that only WINPHO needs the most current user file.

Although this approach is convenient, some administrators have needs that still require individual users be identified. An example is Oregon DMV which internally logs all access. WINPHO can easily accommodate the needs of agencies like DMV with logs and audit reports. Again, it is the owner of the data who controls access to those data.

The "state server" function of these proxy units also contributes to the efficiency of the system, but in a different way. Much WINPHO traffic is intrastate, and routing that traffic through WINPHO in Sacramento is, for the most part, a waste of bandwidth. Take, for example, a transaction in which the Identification Bureau of the Oregon State Police (OSP-ID) is seeking a Driver License record from Oregon DMV. Without the Oregon state server, the transaction requires the following:

1. The request travels from OSP-ID to the WINPHO server in Sacramento;
2. The WINPHO server routes the request to DMV in Salem;
3. DMV fulfills the request which travels back to the WINPHO server in Sacramento;
4. The WINPHO server routes the fulfillment to OSP-ID in Salem.

Two facts illustrate the problem with this arrangement: First, OSP-ID and the Oregon DMV Driver License Bureau are approximately 4,000 feet away from each other in Salem. Second, because the WIN/NLETS drop for Oregon is at OSP-ID, all Oregon WINPHO traffic travels through that OSP office. Therefore, the DMV data ultimately destined for that OSP office travels through that OSP office on its way to the WINPHO server in Sacramento, before being sent straight back to OSP-ID by the WINPHO server! This configuration wastes both time and bandwidth. The solution is to install a state server at OSP to handle intrastate traffic that did not need to touch the WINPHO server in Sacramento, and because this application is collocated with the Oregon proxy server, WIN is able to leverage its investment. State servers coordinate with the WINPHO server in Sacramento on a regular basis to ensure that all data, routing, and authorizations are current. In most cases this coordination occurs on a daily basis. However, if updates are needed more often, multiple daily contacts can be scheduled.

[i] There is obviously some overlap in the description of these two deployed-server functions. The terms are used only for clarity and should not be seen as defining the functions of these units.