Functional Specification
Introduction
Host Self-Registration at Stanford is a combination of a self-registration web application and a self-run computer health-check tool. It allows users to register new machines into NetDB on their own and provides a common set of required processes (patching and data security checks) to be run prior to allowing a system to be on the Stanford network. The system also allows for some local configuration on a network segment basis by local network administrators (LNAs).
Self-Registration, Phase II will address the current issues with desktop security, node registration in NetDB, and audited risks around the lack of accurate information in NetDB and achieve levels of customization, performance, scalability, and robustness on top of Phase I. It is still intended as a per-network opt-in service for Phase II.
Functional Capabilities
Port existing code to java and hardware load balance the application for portability, usability, performance and robustness,
Store additional node data in NetDB and allow LNA to leverage the data to manage local network more efficiently and ensure network security,
Incorporate the wireless network as a primary network and allow self-registration of Unix machine Accommodate the existing ResComp registration practices and allow RecComp to leverage features of the Host Self Reg , especially the Health Check tool
Generate logs, metrics gathered by web server and health check tool
User characteristics
Host Self Registration supports self registration from either wired or wireless network for all faculty, staff and off-campus students (Host registrations for on-campus students are handled by Rescomp). However any Stanford affiliates with Sunetid will be able to download and run health check tool standalone. All interactions with the self-registration system will occur via a web browser from the desktop of the user.
General constraints
Will not support wired guest registration.
Wireless guests are redirected to the wireless guest registration.
The application will not be able to make educated guess of node template to use for the host if the host is on a wireless network and the registrant does not have a primary affiliation.
Assumptions
The local network that a host is on can be determined by the shadow IP address temporarily assigned to the host by DHCP server.
There will be at least one node template per network.
In the case where the user belongs to a department which has multiple node templates, the location choices displayed come from the node templates
In the case of proxy registration, node template choices will be based on information of the proxy person.
Other systems
This application will get registrants primary organization information from Ldap server and the Organization registry. It retrieves and stores data in NetDB.
