Infrastructure for Identification, Authentication and Authorization (I2A2)
Many people now access Purdue University resources and services by interacting electronically with computer-based, service-provider application programs. In these interactions, an individual identifies him or herself to the application and requests one or more resources or services. The service-provider application must then answer at least three questions before fulfilling the request: "Who does this person claim to be?", "Is this person really who they claim to be?", and "Is this person authorized to have the resource or service that they are requesting?"
Purdue's Infrastructure for Identification, Authentication, and Authorization (I2A2), has been designed to provide the processes and information required to answer these questions. I2A2 permits service-provider applications to authenticate the identity of persons requesting use of Purdue resources, and answer questions about a person's association with the University and his or her authorization to use various resources. Electronic applications can use I2A2 to ensure that University resources, services, and benefits are delivered only to those persons who are entitled to them.
In the I2A2 system, every person who has a relationship with Purdue is assigned a ten digit Purdue University IDentification number (PUID). This number can be used in place of their names in electronic transactions. The PUID is necessary because an individual's name is not always unique. For example, two people, who both happen to have a name like John L Smith, will each be assigned different PUIDs and thus will be distinguishable in electronic transactions.
The PUID is only a unique form of a person's name. It is not intended to be a "secret" identifier that can alone be used to gain access to services or resources. The PUID is used only as a unique representation of a person's name and thus it no more "secret" than the name itself. PUIDs are used to answer the "who does this person claim to be?" question that the application must answer before fulfilling requests.
Since many people find it difficult and inconvenient to deal with multiple-digit numeric identifiers, I2A2 associates an 8 character alphanumeric "alias" with each PUID. These aliases are generally formed from some part of a persons name and or initials and are thus a bit easier to recall when they are needed.
To answer the "Is this person really who they claim to be?" question, the application must ask for additional information from the user. This will usually be provided by an individual in the form of a "password" or other authentication "token" that is known only to this person. These "tokens" can take many forms, with "passwords" being the most common at this time. In the future, it is expected that more elaborate "tokens," like digital certificates, will be used to provide higher levels of security. I2A2 is designed with the future in mind.The system has the ability to store and process many types of authentication "tokens" and thus can be used for authenticating a personal identity by both current and future electronic applications.
The "Is this person authorized to have the resource or service that they are requesting?" question is the most difficult of the three questions. To answer this question, the application must have access to some very specific information about the user. For example, access to a specific requested resource or service might be restricted to only those people who are students on the West Lafayette campus, are seniors, and are enrolled in BIO 466. I2A2 is designed to acquire, organize, and maintain information of this type for all people that have been assigned PUIDs.
Every night, I2A2 associates PUIDs with information from official University data. Based on the requirements of the active service-provider applications, this information is then condensed into a set of "characteristics" Each characteristic has a value of "Yes" or "No". For instance, characteristics might include "Employee" or "Student" or "Limited-Term Lecturer" or "Registered in CHEM 332" or "Eligible for Recreational Sports Center usage". Computer-based application programs (developed by service providers) can electronically query these characteristics to see if a person fits the service provider's criteria for access to a University resource. Logical expressions can be used to combine characteristics, such as "Is the person with this PUID a Purdue employee, but not a limited-term lecturer, and registered for CHEM 332?" New characteristics can be added as needed for each service provider. All service providers who utilize I2A2 will be using the same data for their decisions, thus reducing the need for duplicate data files to be distributed and maintained throughout the University campuses.
I2A2 System Structure
The I2A2 infrastructure uses an Oracle database for storing PUID information,
and provides network access to three fast DataBase Managers (DBMs) via secure
network interfaces using a number of standard access protocols such as LDAP.
One DBM serves identification requests: I2A2 identification is the process of
determining the PUID of a person making a request for resources. If the person
knows their PUID, no further I2A2 action is needed. If the requestor doesn't know
their PUID, I2A2 can help determine it by some other personal key, such as name,
human resources identification number (HRID), or student identification number (SID).
A second DBM serves authentication challenges: Authenticating is proving an
identity. The person claiming an identity is asked to supply some secret token to
prove that the claimed identity is valid. Often the token is a password, but it
can be a public key infrastructure (PKI) digital certificate or some other form of
privately owned information.
A third DBM serves authorization queries: Authorization determines that a person
with a proven identity has the right to access the requested resources. The
authorizer DBM supports authorization tests by maintaining a set of characteristics
associated with every PUID. A characteristic describes something associated with
the person identified by the PUID. Most characteristics are derived from official
University records, but there are provisions in I2A2 for establishing private
characteristics.
Example: Control Access to restricted web-based information
Requirement
A faculty member in the Mathematics Department has developed a set of instructional
materials for one of their courses, MATH 234, and would like to make it available to
students via the web. Further, the faculty member requires that only students that
are officially registered for MATH 234 be allowed access to the materials.
Set-Up
The web server that hosts the course material is modified to include additional
software processes that can communicate appropriately with I2A2. These processes
are invoked each time a student requests access to any of the restricted material.
Actions
The first time a student requests access to any of the restricted material they are
asked to enter their PUID and the password associated with that PUID. The web server
then queries the I2A2 authentication server, via an encrypted communication channel,
to see if the student's PUID and password match. If they match the web server can
assured that the person requesting access to the restricted materials is indeed
who they claim to be. The web server then queries the I2A2 authorization server
and effectively asks the question: "Is the person who has this PUID a student and
are they also registered for MATH 234?". If the response from the authorization
server is yes, the web server provides the student access to the material and
retains the authorization information and permits it to be re-used for additional
accesses for a limited time.