Connect to the Purdue Home Page

Purdue University

Identity and Access Management

Authentication Realms

The authentication DBM's database can be partitioned into multiple authentication realms. (N.B.: These are not Kerberos or RADIUS realms.) Realms exist so that different departments can set their own policies with respect to authentication security. For example, department a might prefer a different password encryption type than department b. A primary Purdue realm will include all students, staff and faculty who have coordinated career accounts.

Authentication Realm Characteristics

  • Administrators. Each realm has a designated super-administrator (required) and zero or more sub-administrators. The super-administrator is like the UNIX user "root"--all realm operations are allowed. The sub-administrators may be given powers equal to or less than the realm's super-administrator. Super-administrators and sub-administrators are defined in the realm configuration file.

  • Realm members. Realm administrators can join any person in the PUID database to their realm. The administrator may also establish an initial password and install an X.509 certificate for the user. The administrator may also create an access control list (ACL) for the user that specifies whether the user may modify his own password or install a new X.509 certificate. Realm administrators may also unjoin users from their realm.

  • Member policies. Some realms may trust their users more than other realms. For instance, a realm's security policies might not permit its users to change their own passwords, preferring to have the realm administrator assign them. More liberal realms might allow their users not only to change their own passwords, but to delegate that permission to other realm members (e.g., a departmental proxy might change passwords for all I2A2 users in that department).

  • Encryption type. Passwords are not usually stored in the authentication DBM in a clear-text or even retrievable form. Instead, passwords are used to encrypt a constant value and the resulting hash is stored (cf. the UNIX crypt(3) function), or a message digest computed stored. Realms may select a password encryption type from a list of supported algorithms, or may choose to implement their own.

  • Authentication security policies. The authentication DBM keeps track of good and bad authentication attempts on a per-user, per-realm basis. A realm's authentication security policy specifies what actions the I2A2 system should take in response to apparent attempts to guess a user's password. The authentication policy can also limit the number of authentication attempts per second, to slow down "dictionary attacks."

  • Realm trust relationships. Realms may choose to trust authentication credentials from other realms. For example, if a user authenticates to realm "a", and realm "b" trusts realm "a", the user is considered to be authenticated in both realms. Trust relationships are one-way: a realm "a" may trust a realm "b" that does not in turn trust realm "a". Two-way trust relationships must be explicitly established. Typically, a realm that uses a weak encryption method might choose to trust a realm that uses a strong one, but not vice versa.

Feedback | Contact Purdue | Style Standards
Maintained by: IAMO Team

Purdue University, West Lafayette, IN 47907, (765) 494-4600
© 2010 - 2013 Purdue University | An equal access/equal opportunity university | Copyright Complaints
If you have trouble accessing this page because of a disability, please contact the CSC at itap@purdue.edu or (765) 494-4000.