Version: 0.3 - 12/11/2002
http://yendi.cc.cmu.edu/work/friends/fr-over.html
There is a growing need to provide access to Carnegie Mellon computing resources to people that would not normally qualify for a computer account at Carnegie Mellon. A sample listing of these people are: people collaborating with specific projects hosted at Carnegie people; people in industry working with a student's Blackboard project; external portal users.
This document presents describes a system named FRIENDS.CMU.EDU to address this need. This system provides a simple, easy mechanism for end users to create and manage an account. Service providers who want to serve this audience can do so in the same manner as they serve current Carnegie Mellon users and clearly identify the two communities.
We expect the following major systems to be using FRIENDS when it becomes available:
This project is currently in the pre-discovery stage. No resources have been allocated; no delivery date set.
The purpose of this document is to provide a framework for discussion to determine whether or not it is worth the effort of going into discovery or if the proposal should be discarded.
We are currently assuming that this project is not immediately needed. Blackboard and OLI will have their own mechanisms for dealing with external users. The portal will not require external user access until Fall 2004.
All users of this system are required to have a valid email address. We will also likely only allow one account per email address.
Accounts will be created by the user. A possible implementation will be that a user goes to a web page to create their account. A verification string is emailed to the address they provide. The user will then provide the verification string to set a password.
Once the user has an account, when they hit a protected service, such as one using WebISO, the user can log with that account but needs to make sure to login to the FRIENDS.CMU.EDU realm.
Account maintenance will be handled via interaction with the email address. If the user forgets their password, then a verification string can be emailed which would then allow them to reset the password.
The service provider will need to be able to support multiple realms.
The service provider must also understand that the security policy for the FRIENDS.CMU.EDU realm is much more lax (on purpose) than for other realms. There is not a strong binding between the account and a person. All you know is that an account is associated with an email address.
Service providers must also understand that account names can and will be reused after a period of inactivity. A GUID will provided per account so one recommends using the GUID value for a unique index.
In the case of WebISO, authn will be taken care of by the WebISO system. However, authz is still up to the service.
Are we going to help out with authz? For example, will the LDAP group mechanism flexible enough to support principals from multiple realms?
The system should be self maintaining as much as possible. For example, accounts should be automatically recycled after a period of inactivity.
Care should be taken to provide a good usage reporting mechanism.
What kind of Admin UIs do we need?
Who is
going to do end user support?
We chose to have a separate Kerberos realm rather than including all these accounts in an existing Kerberos realm for the following reasons:
People with Carnegie Mellon accounts will be allowed to create a FRIENDS account. I don't see any benefit at this point but I also don't see a detriment.
Do we link the FRIENDS account object to the Person object in LDAP? I lean towards no because then that bypasses some of the alternate domain checks.
The issues come up for people who are not currently affiliated with Carnegie Mellon but may become so at a later date. The most common example are prospective students.
The correct behavior follows the current behavior. An ANDREW account is not created until the student pays a deposit. Until the deposit is paid, the only account that is available is via FRIENDS.
The major problems that may result from this comes into play if the user has vested interest in their existing FRIENDS account. For example, if they have been using their FRIENDS account since middle school, we are now forcing them to possibly a different account name and requiring people to change all their authz systems to deal with the new account.
It is possible that if this were to happen, the user would be able to continue to use their FRIENDS id as their primary account and only use their ANDREW account when required. It is also possible that this scenario is not likely to happen and so dealing with the situation as a one-off issue may not be a big deal.
The Andrew For Life (xref AFL document) service is independent from this proposal. Andrew for Life is the system to allow existing ANDREW accounts to continue to be used after the user leaves the university.
Both systems share similar goals in facilitating greater interaction with people not currently or directly affiliated with Carnegie Mellon. However, with Andrew For Life, one presumes that there has been a strong binding in the past between the account and the person and, as such, it is a more trusted account.
It is possible/likely that there will be code reused with the two projects and some amount of overlap (where users may have accounts in both realms). At a future date, we may want to revisit how both systems interact as we have no experience at this point with either system since neither have been fully specified, let alone deployed.
This system provides a good deal of flexibility for future services. Complete ISP (e.g. hosting personal web pages, email, etc). could be provisioned in this framework provided that there are sufficient resources to maintain the service.
Possibly the highest cost in providing additional services will be the abuse issue. For example, if we allow sending email via this mechanism, what is to stop a spammer from creating a bogus hotmail account, using that to create a FRIENDS account, and then sending out a ton of spam? (A possible solution is to require a valid credit card for extended services and charge a small amount a year for authn purposes).
It is also possible that much of the code written for FRIENDS.CMU.EDU could be directly applied to ANDREW.CMU.EDU.
AFS integration? Easy enough to set up an AFS cell
but where do these people actually get a shell account?
Windows Domain integration? Probably not that hard
either, just more work and hardware.
Can we get rid of guest accounts with this?
We may want to have account@friends.cmu.edu forward email to their actual address. This would be an easy way for applications to contact the person who is using the account.
We need to decide whether or not the person's actual email address is visible. What level of anonymity do we want to provide?
0.3 - wcw - 12/16/2002 - added project status section 0.2 - wcw - 12/10/2002 - added leg comments 0.1 - wcw - 12/09/2002 - Initial draft