Kiwi is the UW NetID password management system. Kiwi takes passwords and securely distributes them to all the authentication systems that need them.
As passwords are changed, a Kiwi primary component adds that password event to its event queue. The Kiwi primary then notifies a Kiwi Listener component on each of the authentication systems of the new password. When all the Kiwi Listeners have successfully processed the password change, then the password event is removed from the event queue. The Kiwi architecture is centered on passwords, but by extension, this means it also is the account provisioning/deprovisioning agent for UW NetID accounts in the various systems represent UW NetIDs.
The Kiwi system by itself does not know about UW directories, nor does it know about distinctions between UW NetID types, nor even know about the uwRegID associated with UW NetIDs. It simply deals with the UW NetID value and the password associated with that UW NetID.
The NETID domain, of course, has one of the Kiwi Listener components mentioned above, and this is how all account provisioning and password synchronization is accomplished. The NETID Kiwi Listener is called Fuzzy_Kiwi. It’s called Fuzzy_Kiwi because historically it had some added functionality that blurred the lines beyond the Kiwi system’s core intention. Fuzzy_Kiwi had some SubMan components included (see separate SubMan section), and also does some PDS whitepage queries to provision a richer NETID user account. But the SubMan components have been retired, so it isn’t so fuzzy any longer.
UW NetIDs are created and managed via the “Manage my NetID” page and various UW-IT tools. These tools interface with a set of APIs, which handle all communication to the backend UW NetID database and other repositories.
Passwords in the UW NetID space are securely distributed by a service called Kiwi – the box on the upper right. When you change your password in one of a handful of places (i.e. the Manage page, ‘passwd’ on Homer, Dante, or another UA host, kpasswd on any trusted Kerberos system), they send your new password to the Kiwi server, which then distributes it to the Kiwi clients (like the UW’s KDC and the NETID domain controllers.)
When a UW NetID gets created for a person (using the “Get Your UW NetID”, or “newid” site), the UW NetID infrastructure does a couple of things:
- Creates the UW NetID in a backend database within the Identity Registry
- Assigns your UW NetID one or more categories (undergrad student, grad student, staff, faculty, alumni, etc.)
- Based on your categories, activates some basic services – including the Kerberos/Windows principal subscription
The newid site calls an API to activate the subscription – using the Kerberos principal subscription example – newid tells the API what your new UW NetID is and what your password is. The API then passes your UW NetID and password off to Kiwi. Kiwi takes it and tells all of the Kiwi clients to create a principal for your UW NetID with your password. Once that’s been done, Kiwi reports back to the API with a green light that it was finished – the API then marks the Kerberos subscription as Active in the backend repositories.
In the NETID domain, we have a Kiwi client. When we get a command from the Kiwi server, we figure out what Kiwi is trying to tell us, then do a couple of things – for the example noted above, our Kiwi client creates the user account in Active Directory and sets the password.
The traditional model of Kiwi includes some helper processes – in our case, our Kiwi Listener calls methods that handle the dirty work of manipulating Active Directory – creating the account, setting passwords, etc.
The Kiwi architecture also handles account renames. The old UW NetID is saved to the uwPriorNetID attribute.
When there is a known UW NetID compromise, the UW NetID is put through a process which from the user’s perspective denies them access to UW-IT services until they contact UW-IT, correctly establish their identity, and change their password. From the perspective of Kiwi, this event is simply a password change to a password unknown to the user.
The Kiwi architecture also supports the concept of a delete. Fuzzy_kiwi does not delete NETID users when it receives a Kiwi Delete. Instead it disables the account, resets the password, renames it, and moves it to a special location. We don’t immediately delete the NETID user outright to prevent accidents from creating a situation that aren’t easily recovered from.