The Andrew for life project offers Andrew services, in particular email and web access to an audience that extends beyond current Carnegie Mellon students, faculty and staff. The project is part of CMUs intention to extend our relationship with its various community members. In particular to extent the relationship with students beginning from the time they apply and then throughout their lives. Life begins, after all, when you apply to Carnegie Mellon. There are others though, beyond students that are members of the Carnegie Mellon community: research partners, community development partners, trustees, members of advisory boards, those donating to the University, executive students, part-time or temporary employees, summer students etc.
The project provides specific services to applying students and graduating alumni and in addition provides the framework for offering different subsets of Andrew services to different member groups by providing for an authorization framework for all applications. See Appendix C for a list of perspective services appendix B for a list of member groups. The project also provides for ways to adjust policy concerning services provided to groups by a “role-based” mechanism.
Offering email entails offering some kind of client support, the simplest to support is a webmail interface since it requires no configuration support and no software distribution. A policy decision may be to limit access to only webmail for off-campus members. Another support stance is to require new students to enroll in auto-password resetting. This service will enable students to reset their passwords to a known value (SSN?) by answering some secret questions. The importance of this offering really extends after a student leaves CMU since password resets are a frequent support issue.
Offering these services requires some policy changes, additional funding, new software offerings and significant changes to Computing Services software infrastructure
Applying students require limited access to Andrew services. The first is a unique identity that allows them to authenticate in a secure way. Today we think of this as the Andrew-id and typically assign them to arriving students. The identity gives applying students access to two other core service, web content and email. The web content may provide deeply personalized information like admission status and financial support status but also might provide access to more general information like campus phone numbers, dorm locations etc. Incoming students will also need email addresses, today the convention provides and email address of the form Andrew-id@andrew.cmu.edu
All the other Andrew services are at least at the moment unavailable until a student is accepted and commits to the admission. Today’s policy is when a student arrives on campus they have the opportunity to customize an email address once to the form cmu-name@cmu.edu.
When a student graduates, their relationship with CMU changes. All the services generally necessary to live on campus are reduced. An alumni is again generally reduced to having an identity, an email address and having access to alumni specific web content
Today our policy and underlying technology make it difficult for clients to change identities or email addresses. The demand for this is modest because of our relatively short relationship with students and many staff members, that is a few years. Still things happen, people change their names or get ones automatically generated that are somehow offensive. Andrew for life changes these rules. More identities will be in use and the identities will be in use longer. This will make one or more identity or email address changes likely. We also want to offer a higher degree of personalization. All this requires us to allow for more frequent identity changes, email address changes and for potentially the transferring of identity from one person to another.
This is difficult with majority of our services that have been constructed with the notion that once you get an Andrew identity it never changes and that you get any service that you have requested. The accounts systems “DAMS”, the underlying operating systems and most applications are built with this assumption
We can make identity changes less common, in particular by providing new students with an ability to choose an identity and good guidelines ( and enforecement) for picking them . I can imagine that “bighairydudewith2tatoos” might be a very compelling identity at 18 .
A flexible notion is to separate identity from login-id and email address. Things like authorization lists and mailboxes can be built using an underlying and unchangeable identity , while the directory service provide the ability to map between transient or perhaps login-ids and email address into core elements.
There ought to be an application that the registrar provides to new students that lets them picks from a sensible universe of initial identities and login addresses. What algorithm should be used?
You can’t offer services without offering support for those services and you must have policy to deal with extra-ordinary use of those services, either abusive use or over use or un-intended commercial use. Additionally there are issues enforcement of policy and its consequences. Imagine a wealthy alumni running an illegal or for profit service and threatening legal action when their identity is disabled.
Who answers the phone when alumni call for help and what expectations are reasonable. Can alumni pay for support and where does the money go?
Having good demographic information about all Andrew users is necessary for limiting liability through abusive use, policy enforcement and determining level of service.
The two alumni services that seems necessary are resetting passwords and modifying identities and email addresses.
The existing base of Andrew users is somewhat predictable in size and utilization of underlying computer and networking resources. Decreases in the cost of computing have made support the growing needs of a relatively stable base affordable within the existing funding model. The addition of an external and ever increasing client base will likely require a different funding source .
Our notion of an Andrew account providing everything to everybody needs to change given the economics of centralized IT and the expansion in clients discussed above.
For example today we attempt to license software on a site-wide basis, buying to for all 15000 or so active accounts. We can’t extent this outside of this number without occurring real additional costs. Also very little software is actually used this way and we maybe able to save money by licensing to smaller portions of our community. There will also be increasing difficulties with Geographic dispersion , remote students and remote employees, different legal issues, currency, national security concerns.
All this dictate some changes to our user accounts system, DAMS and our campus directory. The various entitlements(or rights) available to Andrew users that are of core concern will need to be specified and organized into common subsets and associated with the various “roles” than a person fills. Some of this work is being done in the current “groups” project which is schedule for complete by the end of 2003.
All new users are created with an Assigned User Id (AUID) or identity. We will pick an algorithm for name creation that many folks may be able to live with without change, e.g. Poepping423 or dopiraktg34. The exact format of the AUID does not matter as long as it is it will be reasonably unique until the end of time.
Users are then given the opportunity to overaly their AUID to a Personalized User Id (PUID). The PUID is any character string that the user wishes to chose that is not already in use by a previous AUID or an in use PUID. The Assignment of a PUID is essentially a name change and will trigger a lot of activity in underlying systems. The AUID is preserved in the namespace. All users , students, staff, faculty and friends will be follow the same process but the recycling and PUIDs for staff maybe occur quicker
The user will be able to keep the PUID until such a time that the user no longer participates in the Carnegie Mellon community. The PUID is then retired and eventually made available for reuse.
The user will be allowed to reactivate the AUID if he returns at a later date but will then be treated as if that AUID had just been created: meaning that all email and all aspects of their Carnegie Mellon University entitlements will be erased and not archived His former PUID is no longer associated with the AUID. If the former PUID is available then the user may select it. Otherwise, the user will need to select another PUID.
All underlying systems will need to be contructed to support the creation, modification and deletion of AUID/PUIDs and email addresses. Most likely this will occur as a side effect of changes being made in the campus directory and each underlaying application and system will be notified via an asynchronous event delivered to an application/specific event handler. The existing mechanism, the trigger server, uses HTTP to deliver directory events to external systems. This mechanism has insufficient transactional integrity or throughput for email-for-life
The following is a list of plans that were discussed but rejected.
Highest use case scenario:
Existing AndrewIDs: 60,000 Alumni without Andrew IDs: 30,000 (per Martha Baron)
Existing Andrew IDs calculated by the fact that we've created about 65,000 Andrew IDs at this point. We round down by 5,000 for random faculty/staff that won't get their ID reactivated.
Let's assume the average age of a graduating senior is 21. Let's say that average life expectancy is 85. So it will take 64 years before the increase of user stabilize.
Let's assume the average number of students graduating (including graduate students) is (at most) 2000. This project doesn’t account for a huge increase in distance students
So, 64 years times 2000 students or 128,000. Add that to the current base of 90,000 from above then we get 218,000. So let's round up and say 250,000.
So worst case just counting students, we have about 20x more active users than before.
In less than 10 years, we will double the user base.
In general, we can probably assume that Moore's law will allow a consistent hardware funding level to keep the steady state. However, the economics predicted by Moore's law clearly does not extend to staff time nor is there any indication that this will continue.
As mentioned above, at this point in time, authentication and authorization are very closely tied with each other. Specifically, if you can identify yourself as a valid 'Andrew' user then almost all services allow you to have access.
How much quota do we give? Hardware cost for something backed up is about 7 cents per MB. I presume we start with Email but will want to be able to roll out Web, AFS and/or other shared space... probably delivered at around the same cost point.
Quota will likely have a direct relation to the internet bandwidth consumed. Current costs are $350K for about 7MByte/sec.
It might occur that an account is expired and then is requested to be reactivated. Who processes the request? How is identity verified? Is there every a situation where information from an account is archived?
What are we going to do about CMU.EDU namespace?? There’s no good answer at this point. The background is that CMU.EDU namespace was the place where people could create their vanity email addresses. The names should be going through the same quarantine and reuse period as is proposed with this system. If we have a new system where people can create their own IDs, does CMU.EDU have a place in it? Should we try to create a CMU.EDU name that matches the user's PUID? The CMU.EDU name is nice to have since it is nice and short and one can argue that if a user has a CMU.EDU name then they are likely going to want to keep using it.
Once alumni data is in the directory, who gets to see it? Can alumni search it, students , internal administrators? What is the policy is this area. What happens to the historical data in a student’s record? Is the data about on campus or home addresses deleted or archived or is it just replaced by alumni data when it arrives. We need to get both alumni data and good “graduation” data.
Making a lot of Applications Directory Aware, training, documentation, policy. We need to get people to be sure to use the Directory to determine authorization information. Given that ids can change, if a careless application developer uses the ID then they could inadvertenly grant access when it should not be granted (or deny access).
We will need to interact with existing alumni systems so that we can retain reasonably up to date information about an alumni's where-abouts, we may even want to give alumni a change to submit changes to this This is important because our accounts managment system is directory centered and requires an amount of quality information about people in the directory for uniqueness to occur We need to be more aware of changing the affiliation of somebody to ALUMNI when they graduate and get good information about what department they graduated from. This brings up the sticky question of historical data. Suppose someone graduates and their department is renamed or is eliminated? Standard datawarehouse practice tend to keep the original historical name plus the contemporary one.
Graduating students will have their entitlements reduced by not eliminated. This is new functionality throughout our systems because it is a change from our all or nothing entitlement strategy. So what do we do with all the data that the person is no longer entitled to have? How to we purge mailbox down to 10% of its quota? Do we allow others to take ownership group data belong to a person?
The AUID should be reasonably unique until the end of time. However, the hope is that many users will not chose to create a PUID so we should make the AUID as useable as possible.
To be friendly, the first part can consist of a person's first name plus their last initial, their initials, or some other form of their name. It would probably be a good idea to limit the first part to be 6 characters or less.
The uniqueness requirement can be addressed by tacking on numbers to the end of the first part. Eliminating the digits '0', '1', and '8' would be good to avoid confusion with 'o', 'l', and 'b'. Having 4 digits should allow 2,401 combinations for each first part.
It should be trivial to add another digit in the event that 2,401 are insufficient. As such, one should *not* assume that the maximum AUID length is 10 characters.
Students Staff and Faculty Alumni Proto-Freshmen (applied not accepted) Pre-Freshmen (accepted not-arrived) Trustees Guests Group owned accounts (Departmental Accounts) Students, Staff, Faculty on leave Sponsored accounts (paid research accounts) Friends of Computing Services Friends of Carnegie Mellon Part time students, faculty,staff. Courtesy appointments Friends of Technology transfer etc. Folks that have pre-Kerberos machines and AD only accounts pre-college ( summer students) students at remote campuses Distance Learning students
. A kerberos principal name, the heart of our authentication system . Andrew Unix file space . Andrew Windows file space (planned for DSP customers) . AFS Project volumes . Web publishing collections . Sponsored computer accounts . Club accounts . Mulberry Address Books . Cyrus mail storage . Andrew Calendars . Personal web collections on www.andrew.cmu.edu . Personal Groups, owned administrative groups . White Pages data . VPN access . Dialup access . Request Guest accounts . Register computers (wired and wireless) in Netreg . Create bboards and majordomo lists . Create Remedy incidents and maintain history . Retain Portal preferences . The right to download Site licensed software . An account of with Active Directory that supports legacy clients (W95)
STUDENTS
Undergraduates
Graduate
Masters
Professional Masters
PhD
By College affiliation
By Major department
Disabled students
Non-Pittsburgh students
Silicon Valley
Greece
Brazil
India
Mexico
Distance Ed students
Executive Education
Ad hoc student groups
PROSPECTIVE STUDENTS
Undergraduates
Graduates
Masters
Professional Masters
PhD
By College of interest
By Focus Segments (there are many more than are listed here)
Ethnic Minorities
Women
In Science
Legacy
Disabled students
EMPLOYEES
All current employees
Non-Pittsburgh employees
DC
Colorado
New York
Silicon Valley
Greece
Brazil
India
Mexico
Disabled employees
Benefit-eligible employees
TES employees
Former employees
Family of employees
Ad hoc employee groups
FACULTY
All current faculty
Tenured / Non-tenured
Emeriti
By College
By Department
Post docs and fellows
Visiting scholars
Special Faculty
Adjuncts
Ad hoc faculty groups
STAFF
All staff
By department
Professional staff
Administrative staff
Staff at off-campus locations
Ad hoc staff groups
ALUMNI
All Alumni
By College (inc. Margaret Morrison)
By Major Department
By region
By reunion year
Executive Education
E-mail for life users
Board members (boards are either university-based or college-based)
Chapter leaders
Volunteers
Academy for Lifelong Learning members
CMACers (alumni interviewers)
SIG members (not necessarily related to major)
Ad hoc alumni groups
TRUSTEES
PARENTS
Of current students
Undergraduate
Graduate
Of prospective students
Of former students
DONORS
Alumni
Current donors
Prospective donors
Non-Alumni
Current donors
Individual
Corporate
Prospective donors
EXTERNAL ENTITIES (in no particular order)
Library Patrons
Walk-ins (virtual and in-person)
Library Consortia
Alumni Academy for Lifelong Learning (ALL)
Spouses and family members of faculty, staff and students
Visiting Affiliates
Special Programs (for example Pre-College, PA Governor's Summer School)
High School Counselors
Summer Program participants
Employers
By Industry Focus Segments
Corporate Recruiters
Hiring agencies
External faculty
Domestic
Foreign
Corporations & Foundations
Governments agencies
Media (Publicity Outlets)
National
Trade
Local
Broker Services
Broadcast
Print
On-line
Interested parties
Researchers
Think Tanks
Other universities
Pittsburgh Community Neighbors
Friends of Carnegie Mellon
By College
Advisory board members
Opinion leaders
Former faculty
Computing Services partners
Corporate partners
Higher-ed partners
General Higher Ed Clients
Purchasers of computing equipment and software
GENERAL PUBLIC
Special Geographic Segments
New York
LA
Silicon Valley
Baltimore/DC
Philadelphia
Boston
Everyone else
0.8 - 12/11/02 - General reformatting, conversion to HTML, minor edits. 0.7 - 08/02/02 - More text added on the beginning describing the projects, some redundant text removed. 0.6 - 07/16/02 - Slices of consituents added from portal project 0.5 - 06/07/02 - More about entitlements and some comments rolled in 0.4 - 04/29/02 - cleaned up formatting; added some comments. 0.3 - 04/29/02 - Directory fears, policy and clarifications 0.2 - 04/23/02 - Add death comment. 0.1 - 04/22/02 - Initial version