|
| 8/07/98 |
If I were to start over from scratch knowing only what I currently know, here's how I would design the UWNetID creation, maintenance and expiration process. If this is useful at all, hopefully it (or pieces of it) can be backstitched into the current implementation.
I envision validation information coming from many sources that will allow one to create a UWNetID. The classic examples are HEPPS, Student Enrollment, the Clinicians, the WAMMI/B3 group and the Cle Elum School District. I think we should be able to create a system that treats all these sources basically the same.
These sources consist of some unique identifier (XID)* and secrets. In the case of HEPPS, the XID is the staff or faculty EIN and the secrets are EIN, last name and date of birth. For students, the XID is the student number and the secrets are the student number, last name, date of birth, and PAC. For the astrology group, the XID might be their membership number and the secrets might be last name, mother's maiden name, astral birth coordinants, etc. The bottom line is that we don't really care what is used to validate these people as long as their XID doesn't change (or we at least get notified when it does).
When people connect to WebNew to validate against one of these sources, they are given the option of linking to an existing UWNetID or creating a new UWNetID. We may encourage using an existing UWNetID by issuing an early prompt "Do you have an existing UWNetID?". If the answer is yes and a valid UWNetID and password are given, it is used. The second question is "Which validation source are you going to use?" If they've got a student UWNetID and they want to link it to their staff EIN, cool. If they've already got another UWNetID linked to their staff EIN then we'd have to ask them to dissociate it first. It's not required, though. If they want a separate UWNetID we'll treat them as separate people, the way we do now.
When little Billy connects from Cle Elum High School he creates a UWNetID associated with his Cle Elum School District student ID number. When he gets accepted to the UW he already has a UWNetID and links it to his new UW student number and maintains whatever state he had previously.
Internally, we'd keep the UWNetID and the list of XIDs from each source that it is associated with. When a UWNetID is no longer associated with any sources, it is removed. We delegate maintenance of the sources to other parties. Bill Urich is in control of the Clinician validation source. He updates the source directly, adding or removing entries. For WAMMI/B3 or Cle Elum they would likely give us a flat file periodically. We could could do our own diff from the previous file to compute additions or removals. Cle Elum should remove little Billy when they want his UWNetID to go away. That would be after 10th day fall quarter if he graduated from high school the previous spring. In any case, when the XID is deleted from the validation source, it must also be deleted from the association table.
When a UWNetID is linked to or dissociated from a source, the source would have to be able to figure that out. Thus if Dr Smith runs WebNew and associates his drsmith UWNetID to his WAMMI/B3 entry, then authenticates through the WAMMI web page, their server needs to have authorization to ask "Is drsmith a WAMMI guy?" or "What is drsmith's WAMMI XID?". If they delete drsmith's XID from the WAMMI validation source we should answer "no/none" to those questions. Preferably in real time. The WAMMI server might be allowed to ask "Is drsmith a clinician?", but shouldn't be allowed to ask "What is drsmith's clinician XID?" (or at least we shouldn't answer) unless they provide some creditial that indicates that it's okay for them to ask.
We would also need to have a dynamic group association. There might be a K-12 group that would include all the people from Cle Elum as well as 20,000 other school district sources. Maybe even a "Washington K-12" group that would be a subset of the "National K-12" group.