Information Technology at Purdue

• Glossary
• Contents
• Characteristics
• Identification
• Authentication
• Authorization
• Protocol
• Contact Information
• Purdue Person Search Documentaiton

• An Oracle database where PUID information is stored.
  
  The database is fed from official University sources, sometimes called Operational Systems, and from specially authorized web sources. The PUID Oracle data base is where PUIDs are created and only its data feeds may cause PUIDs to be created.
  
  One web feed, called the Secure Web Interface (SWI), can be enabled for University staff in many departments. The other web interface is restricted to representatives of the Operational Systems that feed data to the PUID Oracle database.
  
  You can get more information on the web interfaces and conditions for becoming an authorized user here.
  
  
• A Reflector Data Base Manager (DBM) for the PUID Oracle database.
  
  The reflector exists to locate PUIDs -- i.e., answer the identification question -- in a more rapid and efficient manner than could be accommodated by the PUID Oracle database.
  
  The reflector will accept as lookup keys:
  • A person's Coordinated Purdue Career Account Login
  • A person's full name or a regular expression of the name (See Name Regular Expressions.)
  • A staff member's Human Resources IDentification (HRID) number, currently the person's Social Security Number
  • A student's Student IDentification (SID) number, also often the person's Social Security Number
  
  In response to a successful query the reflector will return a positive acknowledgement (ACK), accompanied by the PUID, the associated alias, and the name of the person to whom the PUID is assigned.
  
  Note: while HRID and SID may be used as lookup keys, the reflector never returns them as location information.
  
  In response to an unsuccessful query, the reflector normally returns a negative acknowledgement (NAK).
  
  In response to a regular expression search for name that yields no unique answer, the reflector will return a NAK, may also return a list of possible matches.
  
  
• An Authenticator DBM that serves to prove identity.
  
  The authenticator DBM provides the ability to verify a claimed identity, PUID or alias, by accepting a secret token over a secure, encrypted channel, encrypting it with the appropriate method, and comparing it to a stored encrypted copy of the secret key.
  
  The secure channel uses the Secure Sockets Layer (SSL) protocol. At the end of the SSL channel setup, the client host can verify that the channel connects to the authenticator DBM.
  
  The secret token is usually a password. It may also be an X.509 certificate.
  
  The encryption method is defined by the authentication realm identified by the calling client host system. The default realm is the Purdue Realm, currently containing passwords borrowed from Computing Center coordinated career accounts. The authenticator DBM does the encryption to relieve client system designers and administrators of the need to support all possible encryption methods. More information on realms may be found here.
  
  Encryption is not required for X.509 certificates, since their security is based on the Public Key Infrastructure (PKI) foundation.
  
  Note that the authenticator DBM never stores secret tokens in clear text, only their encryptions. Note also that when the secret token is transmitted by the client host to the DBM, it must be done over a secure SSL channel, and the identity of the server side of the channel (the authenticator DBM), can be determined.
  
  
• Authorizer DBM that answers questions about a PUID's characteristics
  
  The authorizer DBM stores information about the person associated with a PUID in the form of Boolean (true or false) characteristics.
  
  Characteristics represent known associations the person has -- the person is a student, an employee, is enrolled in a particular course, is an employee of a particular department with a particular job classification, the student has a particular status or registration school.
  
  Here's a quick look at the currently available characteristics. It's possible to request new characteristics be added to the currently available list.
  
  A client host may ask the authorizer DBM to evaluate questions about a set of characteristics for a PUID. For example, the client system may ask if the person is a student who is enrolled in a specific division and section of a specific course. It may ask a more complicated question that combines the student, course, and division expression with the condition that the PUIDs person is not an employee. Those questions are stated by the client system as a Boolean Expression.
  
  When the authorizer DBM is asked to evaluate a Boolean expression of characteristics for a PUID, the request is supplied in a lookup command, and the value of the expression will be found in a field accompanying a positive acknowledgement (ACK) reply. When the person indicated by the lookup key can't be located, the authorizer DBM returns a negative acknowledgement (NAK).

DBM Abbreviation

Standard abbreviations are used for the I2A2 DBMs:

• authc - for the authenticator DBM
• authz - for the authorizer DBM
• refl - for the reflector DBM

Contacting a DBM

Although this section has implied that client hosts exchange dialogs with the DBMs, in reality there is an intermediary, called the net daemon, that handles client host communications with the DBM.

There are two net daemons for each DBM. One listens on a plain text port; the other, on a Secure Sockets Layer (SSL) port. Port assignments may be found here

Communicating with a Net Daemon

Client hosts and net daemons communicate via a simple text-based protocol, sometimes also called the external protocol to distinguish it from the internal protocol used between the DBMs and the net daemons. The protocol is described here.