Andrew For Life (2002)

October 6, 2002; $Id: afl.html,v 1.1.1.1 2003/02/25 19:35:04 wcw Exp $

http://yendi.cc.cmu.edu/work/eflv2/afl.html

1.0 Introduction

Andrew For Life (AFL) undertakes the project to extend the computing infrastructure to Carnegie Mellon community members. Example community members are alumni, prospective students, parents, research partners, etc. We believe that fostering and maintaining the relationship with individual and providing the framework within which they can continue to participate in the Carnegie Mellon community will be mutually beneficial and rewarding.

There are several dependencies with other documents:

• FRIENDS.CMU.EDU - Infrastructure to allow interested parties to participate in the Carnegie Mellon community. These people include parents. friends, etc.

• Authorization Infrastructure - This document describes the plan for dealing with authorization, in particular, we talk about entitlements and roles in this document.

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.

Initially the project provides specific services to applying students and graduating alumni while retaining services to existing staff and students In addition the project provides the framework for offering different subsets of Andrew services to different member groups by providing for an authorization framework maintained via the Campus Directory Service.  See Appendix C for a list of perspective services appendix B for a list of potential member groups. The project also provides for ways to adjust policy concerning services provided to groups by a (with some guidance from RBAC).

Andrew for life requires some policy changes, additional funding, new software offerings, changes to existing services and significant changes to Computing Services software infrastructure.

1.1 Students, user-ids, email addresses

Applying students require limited access to Andrew services. The first is a unique user-id 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 user-id 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

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.

All the other Andrew services are at least at the moment unavailable until a student is accepted and commits to the admission.  Customization within 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. With customization via Andrew for life what happens to the cmu.edu namespace? See section 12.8

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 a user-id, an email address and having access to alumni specific web content

2.0 Changing user-ids and email addresses

We expect to support more frequent user-id and email address changes. Today our policy and underlying technology make it difficult for clients to change identities or email addresses.   The demand for changes 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 legally or get user-ids automatically generated that are somehow offensive. Andrew for life changes these rules. More user-ids will be in use and the user-id will be in use longer. This will make one or more user-id or email address changes likely.  We also want to offer a higher degree of personalization. All this requires us to allow for more frequent   changes, email address changes and for potentially the transferring of user-ids from one person to another. 

This is difficult with majority of our services that have been constructed with the notion that once you get a user-id it never. The accounts systems DAMS, the underlying operating systems and most applications are built with this assumption. We also generally make the assumption that possessing a valid Andrew user-id gives the owner access to all Andrew services.

We can make user-id changes less common, in particular by providing new students with an ability to choose an identity and good guidelines (and enforcement) for picking them. I can imagine that bighairydudewith2tatoos be a very compelling identity at 18.

A flexible notion is to separate identity from user-id and email address. The identity is very similar to the US social security number. It is a unique identifier attached to every unique person. The current Campus Directory has such a notion. A 128 bit GUID is assigned to every person and user-ids, email addresses etc are associated with that identity.   Things like authorization lists and mailboxes can be built using an underlying and unchangeable identity, while the directory service provide the ability to provide mapping.

3.0 Service and Policy

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 user-id 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.

4.0 Continuing funding, capacity planning

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. See section 12.

5.0 More on authorization, entitlements and roles

Our notion of an Andrew account providing everything to everybody needs to change given economics and the expansion in clients discussed above. Not every group has the same set of entitlements due to financial, legal or supportability considerations. See section C for a partial list of entitlements.

What entitlements an individual gets really depends on the roles they fill with Carnegie Mellon. Some roles are official in nature and can be derived from HRIS and SIS feeds, for example a fulltime and enrolled student in Pittsburgh. Other roles, like network administrator or project manager are maintained outside of our regular sources of data.

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. An entitlement of “Can download SAS” might be granted to fulltime students, CIT faculty and SCS faculty.

Roles of network or computer administrators would allow individuals to register computers or download software on behave of others. Their role allow them to grant entitlements to others.

All this dictates some changes to our user accounts system, DAMS and campus directory.  The various entitlements available to Andrew users that are of   will need to be specified and organized into common subsets and associated with the set of roles we denote. 

6.0 How it will all work - getting a user ID, changing it, retiring it etc. 20,000 ft. View

All new users are given an Assigned User-Id (AUID) and an 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 overlay their AUID to a Personalized User Id (PUID).  The PUID is any character string that the user wishes to choose 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 nthat 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 based on their role at that time. If the former PUID is available, then the user may select it.

All underlying systems will need to be constructed 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

6.1 More Details

The user is not required to change the AUID. If they are fine with it, that's fine with us.

If the user selects a "bad" PUID, the user may change the ID but there will be a penalty fee charged to discourage this activity and some policy which makes frivolous changes difficult. The fee may increase for each additional change.  The exact fee schedule has not been determined but the point of it is to discourage frivolous changes.

Note that the ability to change have PUIDs and change them adds much complexity to the email for life endeavor but personalization is the whole point. The PUID is used as a unique identifier in many underlying systems.

The exact determination of when a user stops participating has not yet been determined. It is likely to be keyed off of the last time a user authenticated.  We expect this the duration to be years though.

There will need to be a quarantine period on the PUID. During this period, any email sent to the PUID will bounce with a notice that the ID is no longer in use.

When changing the AUID to the PUID and any subsequent PUID changes, the id will likely be unavailable for a certain period of time -- probably less than 24 hours – as the rename takes place.

Some alumni will still choose to forward their email to another location.  Just like existing users have the option of forwarding their email, so would Alumni users. The only "annoyance" for the Alumni user is that they would likely have to authenticate (or do whatever is necessary to show that they are continuing to participate).

7.0 Requirements Analysis

7.1 Why this plan is good

    Existing Andrew IDs:        60,000
    Alumni without Andrew IDs:  30,000 (per Martha Baron)