A Model for an Enterprise-wide User Authentication Service

"Authentication accounts"

• the authentication process would establish user identity without revealing that identity to any observer. That is, the account name would NOT be the user's student number or actual last name or any derivative of their last name, or any reversible derivative of any standard identification information (e.g. a unix encryption of their name).

• as little information as possible would be transmitted in clear text or sent as "hidden" in HTML form pages. In particular, CGI scripts would not send the user account OR the user password OR any encrypted version thereof...but rather WOULD send transaction tokens identifying state information kept in tables local to the CGI processes involved.

• users would be required to present themselves in person with corroborating identification (drivers licenses, student IDs, etc.), before being assigned an authentication account.

Here is a basic model of an approach to an authentication system. First we build a database containing "user authentication accounts" (UAAs), where each entry includes a user account name along with user information like a password, student number, etc. Then we build an "authentication server" that accepts (http-based??) requests for authentication in the form of an encrypted pair....account_name, password.... and responds "yes" if the pair of values match and "no" otherwise. This exchange would be encrypted though there are probably complexities of industrial-strength encryption here that must be considered.

To get an account, a user would come to the Computer Center or Strong Hall or some such location, present IDs and be assigned an account. The user could then manage the account ad lib....change passwords and whatever other information might be relevant.

Note that the "authentication accounts" described above authorize nothing. They are NOT for dial-in access, e-mail access, etc. However, they WOULD be used to authenticate a user applying for online services like an account on falcon, or access to student grades. For example, we currently give dial-in accounts to users who know a birth date that matches a student number. If we had an operating authentication system, we would allow students who know their authentication account name and password, to set up a dial-in account...or access any of a number of other resources as well.

Scaling problems

There are a several possible approaches to this problem.

• First, the university could send account names and passwords directly to matriculating students. Admissions could make this a standard part of the matriculation process. Clerical effort would be drastically reduced, though it would not be eliminated due to the tendency of users to forget passwords and account names (especially when these are assigned TO them rather than chosen BY them.)

• Second, we could set up a system where anyone who knows a student number and the associated birth date (or some other information available in our student records databases), could define a UAA. This is much less secure than requiring users to visit a university office with corroborating identification, but it requires much less clerical time.

• Third, we could define a new database comprised of a set of "meta-accounts", one per university department. The owner of such an account could authenticate herself and then create user authentication accounts after viewing appropriate corroborating identification as above.

  Then everyone on campus could get an account and no one office would be stuck with the clerical overhead, except that some group would have to go through and delete accounts for inactive students/employees. Some departments would probably want to create accounts for non-student/non employee persons who have a special need to use university resources, which implies that accounts would have to have type (i.e., full student account with access to all student privileges, visiting student account with access to some student privileges, visiting faculty, part-time researcher, etc.), and individual departments would have to take the responsibility to delete inactive accounts.

  There might be good reasons for an individual to have multiple accounts, and accounts might need to include additional information. For example, one department might create an account for a part time employee with limited privileges, and another department might create an account for the same person as part of a different university responsibility. it would be possible to keep a single account and just add privileges (along with the authorizing department info), or just create separate accounts.

  Actually, it might be reasonable to allow departments to create accounts of interest only to their scripts. That is, a department might want to use the university-wide authentication server to hold information for their own purposes.

• Fourth, it would probably be possible to set up special online stations on campus that would allow users to authenticate themselves by swiping their University campus card through a card reader and then define their Authentication Account.

  The campus card system will not work for authenticating online resource use for several reasons.

  • First, for the most part we are designing resources to be used from any location on the world-wide Internet, and most of the user interfaces connected to the Internet are not equipped with campus-card card readers. Plus, campus-card card readers will probably be too expensive for most users to buy for their home systems.

  • Second, the project specs used to acquire our system did not require the vendor to provide any kind of network access to any databases developed as the cards are distributed to the campus community. While it is possible that these databases might be acquired, an authentication framework is still required to use them.
  It is currently not clear how we would verify that the user of the card is also the owner of the card aside from simple possesion. If simple possession of the card is insufficiently secure to justify creating an Authentication Account for the card holder, some kind of PIN would have to be assigned for authentication.....which appears to get us into a circular loop.

  During March of 1998 efforts on the part of ACS to add Authentication Account assingment to the campus-card registration process were unsuccessful.

  Michael Grobe
  Academic Computing Services
  The University of Kansas
  

  ---

  Copyright 1998, University of Kansas, Lawrence, Kansas All Rights Reserved